(12) INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT) 



(19) World Intellectual Property 
Organization 
International Bureau 

(43) International Publication Date 
12 August 2004 (12.08,2004) 




PCT 



(10) International Publication Number 

WO 2004/068293 A2 



(51) Internationa] Patent CJassiGcation'': 
(21) International Application Number: 



G06F 



PCTAJS2004/001845 
(22) International Filing Date: 23 January 2004 (23.01-2004) 

(25) Filing Language: English 

(26) Publication Language: English 



(30) Priority Data: 

60/442,486 
60/456,741 



25 January 2003 (25.01.2003) US 
2 1 March 2003 (2 1 .03 .2003) US 



(71) Applicant (for ail designated States except US): PEP- 
PERCOIN, INC. [US/US]; 85 Central Street, Suite 205. 
Waltham, MA 02453 (US). 

(72) Inventors; and 

(75) Inventors/Applicants (for US only): REVEST, Ronald, 

L. [US/US]; 41 Academy Street, Arlington, MA 02476 
(US). MICALI, Silvio [US/US]; 459 Chestnut Hill Av- 
enue, Brookline, MA 02146 (US). SOLOMON, Perry 
[USAJS]; 18 WTilcox Avenue, Pawtucket, RI 02860 (US). 



NIX, Robert, P. [USAJS]; 197 Belknap Street, Concord, 
MA 01742 (US). CARNEY, Robert [USAJS]; 15 Newman 
Street, Cambridge, MA 02140 (US). JONNALAGADDA, 
Varappdsad [TNAJS]; 72 Pearl Street, Newton, MA 02458 
(US). BERGERON, Joseph, m [US/US]; 41 St. Germain 
Street, Boston, MA 02114 (US). BATES, Mark [US/US]; 
64 Regent Road, Maiden, MA 02148 (US). 

(74) Agents: LAPPIN, Mark, G. et al.; McDermott, Wijl & 
Emery, 28 State Street, Boston, MA 02109 (US). 

(81) Designated States (unless othenx'ise indicated, for every 
kind of national protection available): AE, AG, AL, AM, 
AT, AU, AZ, BA, BB, BG, BR, BW, BY, BZ, CA, CH, CN, 
CO, CR, CU, CZ, DE, DK, DM, DZ, EC, EE, EG, ES, H, 
GB, GD. GE, GH, GM, HR, HU, ID, IL, IN, IS, JP. KE, 
KG, KP, KR, KZ, LC, LK, LR, LS, LT, LU, LV, MA, MD, 
MG, MK, MN, MW, MX, MZ, NA, NT, NO, NZ, OM, PG, 
PH, PL, FT, RO, RU, SC, SD, SE, SG, SK, SL, SY, TJ, TM, 
TN, TR, TT, TZ, UA, UG, US, UZ. VC, VN, YU, ZA, ZM, 
ZW. 

(84) Designated States (unless otherwise indicated, for every 
kind of regional protection available): ARIPO (BW, GH, 
GM. KE, LS, MW, MZ, SD, SL, SZ, TZ, UG, ZM, ZW), 

/ Continued on next page ] 



(54) Title: MICROPAYMENT PROCESSING METHOD AND SYSTEM 



< 

m 

O 



offer 
development 
module 



104 ^ f 



PCS module 



micropayment selection 
protocol 



mPSP module 



consumer 
agent module 



f 



0 



cPSP module 




data rights 
management 
system 



'typically 
non-secure 
systems 



typically 
secure 
systems 



(57) Abstract: A method of producing an offer package includes defining, within the offer package, a description of an offered 
^ product. The cost of the offered product and the merchant making the offer are also defined within the offer package, which includes 
an encrypted version of the offered product. 



wo 2004/068293 A2 lllllllllilllililllllllllllllllilllllllllillllii 



Eurasian (AM, AZ, BY, KG, KZ, MD, RU, TJ, TNT), Euro- 
pean (AT, BE, BG, CH, CY, CZ, DE, DK, EE, ES, H, FR, 
GB. GR, HU, IE, IT, LU, MC, NL, PT, RO, SE, SI, SK, 
TR), OAPI (BF, BJ, CP, CG, CI, CM, GA, GN, GQ. GW, 
ML, MR, NE, SN, TD, TG). 

Published: 

— without international search report and to be republished 
upon receipt of tliat report 



For two -letter codes and otiier abbreviations, refer lo the "Guid- 
ance Notes on Codes and Abbreviations" appearing at the begin- 
ning of each regular issue of the PCT Gazette. 



wo 2004/068293 



10/553611 
JC12Rec'c!PCT/Prcl8 0CT2nn 

PCTAJS2004/001845 " 



MICROPAYMENT PROCESSING METHOD AND SYSTEM 

RELATED APPLICATIONS 

[0001] This application claims the benefit of priority to: (a) U.S. Provisional 
Application No.: 60/442,486, filed 25 January 2003, entitled " Method and System for 
Micropayment Transactions"; (b) U.S. Provisional Application No.: 60/456,741, filed 21 
March 2003, entitled " Method and System for Micropayment Transactions"; and (c) U.S. 
Patent Application No.: 10/476,128, filed 27 October 2003, entitled "Method and System 
for Micropayment Transactions", which claims the benefit of priority to Intemational 
AppUcation No.: PCT/US02/12189 (filed 17 April 2002), which claims the benefit of 
priority to U.S. Provisional Application No.: 60/287,251 (filed 27 April 2001), U.S. 
Provisional Application No.: 60/306,257 (filed 18 July 2001), and U.S. Provisional 
Application No.: 60/344,205 (filed 26 December 2001) 

FIELD OF THE INVENTION 

[0002] This invention relates to transaction processing and, more particularly, to the 
processing of micropayment transactions. 

BACKGROUND 

[0003] Now that the era of fi-ee-intemet-content is drawing to a close, consvimers want 
pay-per-use options to complement internet subscription availabihty. While digital content 
owners recognize the potential of pay-per-use models (i.e., for items such as games, music, 
and software), existing payment systems for low-value digital content are characterized by 
high transaction costs, which in some cases exceed the value of the digital content itself 

[0004] Often, banks and pajonent processors levy a minimum transaction fee (i.e., 
typicaUy at least $0.20 ) for every digital content tiransaction, even those tiransactions with 
very low price points. 
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[0005] Unfortunately, these minimum transaction fees constitute a significant barrier 
to profitability for low-priced transactions, and have inhibited tlie growth of markets that 
distribute low-priced content. 

SUMMARY OF THE INVENTION 

[0006] In one implementation, a method of producing an offer package includes 
defining, witliin the offer package, a description of an offered product. The cost of the 
offered product and the merchant making the offer are also defined within the offer 
package, which includes an encrypted version of the offered product. 

[0007] One or more of the following features may also be included. A use duration for 
the offered product may be defined within the offer package. A cvm ency of the offer may 
be defined within the offer package. An expiration date of the offer may be defined within 
the offer package. The offer package may be digitally signed and the offered product may 
be encrypted to generate the encrypted- version of the offered product. 

[0008] In another implementation, a method of producing an offer package includes 
defining, within the offer package, a description of an offered product/service. The cost of 
the offered product/service and the merchant making the offer are also defined within the 
offer package, which includes an encrypted link to the offered product/service. 

[0009] One or more of tlie following features may also be included. A use duration for 
the offered product/service may be defined within the offer package. A currency of the 
offer may be defined within the offer package. An expiration date of the offer may be 
defined within the offer package. The offer package may be digitally signed. A link to the 
offered product/sendee may be encrypted to generate the encrj/pted link. 

[0010] In another implementation, a method of reducing download fraud includes 
defining an offer package, such that the offer package includes a offer description and an 
encrypted version of the offered product, and requiring that a potential consumer download 
the offer package prior to being able to review the offer description. 
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[0011] One or more of the following features may also be included. The potential 
consumer may be required to download the offer package prior to being able to purchase 
the offer package. The potential consumer may be allowed to decrypt the encrypted 
version of the offered product in response to the potential consumer purchasing the offer 
package. The potential consumer may be provided with a decryption key that allows the 
potential consumer to decrypt the encrypted version of the offered product. 

[0012] In another implementation, a method of processing an offer package includes 
validating the offer package, accepting the offer package, detemiining a cumulative spend 
amount for the consumer that accepted the offer package, and generating a micropayment 
token that identifies the offer package and the cumulative spend amount. 

[0013] One or more of the following features may also be included. An offer 
description included within the offer package may be reviewed prior to accepting the offer 
package. The micropayment token may be digitally signed. The micropayment token may 
be transmitted to a token processing system. A decryption key may be received from the 
token processing system. 

[0014] The offer package may concern an offered product, and the offer package may 
include an encrypted version of the offered product. The decryption key may allow the 
consumer to decrypt the encrypted version of the offered product. 

[0015] The offer package may concem an offered product/service, and the offer 
package may include an encrypted link to the offered product/service. The decryption key 
may allow the consumer to decrj^pt the encrypted link. 

[0016] A consumer certificate, concerning the consumer that accepted the offer 
package, ina.y be obtained from a tok^ processing system. The consumer certificate may 
include a consumer identifier that allows for the retrieval of the cumulative spend amount. 
The offer package may be retrieved from a remote location. 

[0017] In another implementation, a method of processing micropayment tokens 
includes receiving a micropayment token from a remote source. The micropayment token 
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concerns an offer package that was offered by a merchant and accepted by a consumer. 
The micropayment token is vaUdated, accepted for processing, and selected for 
micropayment processing. 

[0018] One or more of the following features may also be included. A decryptionkey 
may be transmitted to the consumer. The offer package that was offered by the merchant 
and accepted by the consumer may be vaUdated. The offer package may be verified to 
have not expired. 

[0019] The accepted micropayment tokens may be defmed as either selected 
micropayment tokens or unselected micropayment tokens, such that the selected 
micropayment tokens are used as the basis for paying a macropayment amount to the 
merchant. The accepted micropayment tokens may be defmed in accordance with a 
defined selection percentage. The defined selection percentage may be one percent (i.e., 
resulting in one selected micropayment token for each ninety-nine unselected 
micropayment tokens) or may be ten percent (i.e., restating in one selected micropayment 
token for each nine unselected micropa^'ment tokens). 

[0020] Each selected micropayment token may define a micropayment token amount. 
The micropayment token amount may be increased in accordance with the inverse of the 
defined selection percentage, thus defining tlie macropayment amount The micropayment 
token may be digitally signed, 

[0021] In another implementation, a method of processing selected micropayment 
tokens includes validating a selected micropayment token, and queuing the selected 
micropayment token. The selected micropayment token defines a macropayment amount, 
defines a micropajonent token amount, and concems aji offer package that was offered by a 
merchant and accepted by a consumer. 

[0022] One or more of the following features may also be included. The offer package 
that was offered by the merchant and accepted by the consumer may be validated. The 
offer package may be verified to have not expired. The selected micropayment token may 
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be placed into a processing queue, such that a queue reserve is associated with the 
processing queue. The processing queue may be a FIFO queue. Each selected 
micropayment token may further define a cumulative spend amount, which is the sum of: 
the last amount previously billed to the consumer; and the differential amount that the 
consumer has spent since the last billing. 

[0023] A consumer baiiking institution that is associated with the consumer may be 
billed for the sum of the micropayment token amount and the differential amount. The last 
amount previousl}'' billed to the consumer may be set equal to the sum of: tlie last amount 
previously billed to the consumer; the differential amoimt; and micropayment token 
amount. The differential amount may be set equal to zero. The sum of the micropayment 
token amount and the differential amoimt may be deposited into the queue reserve 
associated with the processing queue. The macropayment amount of a 
next-to-be-processed selected micropayment token within the processing queue may be 
compared to the value of the queue reserve. The next-to-be-processed selected 
micropayment token may be the selected micropayment token in the front position of the 
processing queue. The macropayment amoimt defined in the next-to-be-processed 
selected micropayment token may be deposited into a merchant banking institution 
associated with the merchant. 

[0024] In another implementation, a method of processing unselected micropayment 
tokens includes authorizing for processing an unselected micropayment token, and 
validating the unselected micropayment token. The unselected micropayment token 
defines a micropayment token amount, a cumulative spend amount, and concerns an offer 
package that was offered by a merchant and accepted by a consumer. The cumulative 
spend amount is the sum of: a last amount previously billed to the consumer; and a 
differential amount that the consumer has spent since the last billing. 

[0025] One or more of the following features may also be included. The offer package 
that was offered by the merchant and accepted by the consumer may be vaUdated. The 
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oJBFer package may be verified to have not expired. The iinselected inicropayment token 
may be placed into a processing queue. A queue reserve may^ be associated with the 
processing queue. The processing queue may be a FIFO queue. 

[0026] A consumer banking institution that is associated with the consumer is billed 
for the sum of the micropayment token amount and the differential amount. The last 
amount previously billed to the consumer may be set equal to the sum of: the last amount 
previously billed to the consumer; the differential amount; and micropayment token 
amount. The differential amount may be set equal to zero. The sum of the micropa^onent 
token amount and the differential amovmt may be deposited into the queue reserve 
associated \^dth the processing queue. 

[0027] A predetemiined time period (e.g., thirty days) may be compared to an actual 
time period since the unselected inicropayment token was generated, such that the 
unselected micropayment token is authorized for processing if the actual time period 
exceeds the predetermined time period. A predefined minimum billing threshold (e.g., five 
dollars) may be compared to the differential amount, such that the unselected 
micropayment token is authorized for processing if the differential amount exceeds the 
predetermined time period. 

[0028] In another implementation, a batch encoding method includes defining a batch 
size definition and obtaining two or more data objects that satisfy the batch size definition. 
Each data object is hashed to generate an N^^ order hashed data object for each data object. 
The N^^^ order hashed data objects are grouped into one or more pairs of N^^ order hashed 
data objects. Each pair of order hashed data objects are hashed to generate an 
order hashed data object for each pair of N*^ order hashed data objects. The grouping of the 
N*^ order hashed data objects and the hashing of each pair of N*^ order hashed data objects 
is recursively repeated until there is only one N^"*"^ order hashed data object generated. 

[0029] One or more of the following features may also be included. The N^^"^^ order 
hashed data object may be digitally signed. The number of N* order hashed data objects 
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generated may be an odd number, and the grouping of the N order hashed data objects 
may result in one or more pairs of order hashed data objects and a single N^^ order 
hashed data object.* 

[0030] The single order hashed data object may be grouped with an M*^ order 
hashed data object. The M^^ order hashed data object may be a higher order hashed data 
object than the single order hashed data object. The single order hashed data object 
may be hashed with the M^*' order hashed data object to generate an M^*^"^^ order hashed data 
object. 

[0031] Defining a batch size definition may include defining a time period (e.g., 100 
milliseconds). Obtaining two or more data objects may include obtaining data objects 
made available during the time period. Defining a batch size definition may include 
defining a number of data objects. The data object maj' be a micropayment token (e.g., a 
selected micropayment token or an imselected micropayment token), or an offer package. 

[0032] In another implementation, a verification method includes receiviag a hashed, 
multi-level, data object, such that the hashed, multi-level, data object includes one or more 
hashed, non-target data objects. One or more sequential data keys are received, such that 
each sequential data key corresponds to a hashed, non-target data object at a unique level 
within the hashed, multi-level, data object. A non-hashed, target data object is received. 
The non-hashed, target data object is hashed to generate an N^^ level hashed data object. 
The N* level hashed data object is grouped with an level, sequential data key to 
generate an level object/key pair. The level obj ect/key pair is hashed to generate an 
N*"^^ level hashed data object, such that the grouping of the N^^^ level hashed data object and 
the hashing of the N'^ level object/key pair are repeated for each sequential data key. 

[0033] One or more of the following features may also be included. The hashed, 
multi-level, data object may be an encrypted, hashed, multi-level, data object. The 
encrypted, hashed, multi-level, data object may be decrypted to generate a decrypted, 
hashed, multi-level, data object. The decrypted, hashed, multi-level, data object may be 
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compared to ttie highest-level hashed data object generated to determine the validity of the 
hashed, multi-level data object. 

[0034] The non-hashed, target data object may be a micropayment token (e.g., a 
selected micropayment token or an imselected micropayment token) or an ojBFer package. 

[0035] In another implementation, a secure payment processing system includes at 
least one secure module and at least one non-secure module. A plurality of tokens are 
transfen'ed between the at least one secure module and the at least one non-secure module. 
At least one of the modules executes a micropayment selection protocol that selects one or 
more, but not all, of the tokens for processing from the plurahty of tokens. 

[0036] One or more of the following features may also be included. The at least one 
secure module may include a cPSP module, or an mPSP module. The at least one 
non-secure module may include a consumer agent module, an offer development module, 
or a PCS module. 

[0037] The micropayment selection protocol may establish payment for a transaction T. 
The protocol may include a first party deriving from T a data string C related to T, and 
causing a second party to receive at least a portion of the data string C. The protocol may 
include the second party associating with the at least a portion of C an item V, such that V is 
substantially unpredictable by the first party. The protocol may include the second party 
determining whether V satisfies a property P, and if so, the second party causing a third 
party to receive information I enabling the third party to verify whether V satisfies the 
property P. The protocol may include the third party, upon receiving I, verifjdng whether V 
satisfies the property P, and the third partj' causing a fourth party to receive an amount A, 
only if V satisfies the property P. 

[0038] The micropajaiient selection protocol ma)^ allow a user U to establish payment 
to a merchant M for a transaction T having a transaction value Ty. The protocol may 
include the user establishing a public key and a corresponding secret key for a first digital 
signature scheme, and deriving from T a data string C = SIGu(T) to create an electronic 
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check contaiBing C, such that SIGu(T) represents tlie digital signature of the user U for the 
transaction T in the first digital signature scheme. The protocol may include the user 
causing the merchant to receiv.e the data string C. The protocol may include the merchant 
establishing a public key and a corresponding secret key for a second digital signature 
scheme, and associating with the data string C an item V = SIGm(C), such that SIGm(C) 
represents the digital signature of the merchant M for the data string C in the second digital 
signature scheme. The protocol may include tlae merchant computing the value 
F(V)=F(SIGm(C)), where F represents a public function that operates on a bit string to 
output a number between 0 and 1. The protocol may include the merchant comparing 
F(SIGm(C)) with a constant s to determine whether F(V) < s, and if so, causing a bank to 
obtain the public key of the merchant. The protocol may include the bank using the public 
key of flie merchant to verify that F(SIGm(C)) <s; and only if F(SIGm(C)) < s, the bank 
causing the merchant to receive an amount A= [Tv * 1/s]; such that s is a constant greater 
than 0 and less than 1, and represents the probability that the electronic check be selected 
for presentation to the bank. 

[0039] The micropayment selection protocol may establish payment for a transaction T. 
The protocol may include a first party receiving firom a second party at least a portion of a 
data string C, such that the data string C is related to T. The protocol may include the first 
party associating with at least a portion of C an item V, such that V is substantially 
unpredictable by the second party. The protocol may include the first party dete rminin g 
whether V satisfies a propertj^ P, and only if so, the first party causing a third party to 
receive infomiation I enabling the third party to verify whether V satisfies tlie property P, 
thereby enabhng the third party to cause a fourth party to receive an amount A upon 
verification that V satisfies P. 

[0040] The micropayment selection protocol may estabhsh payment for a transaction T. 
The protocol may include a first party receiving firom a second party information I enabling 
the first party to verify that an item V satisfies a property P, such that the item V is 
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associated with at least a portion of a data string C derived from T by a third party, and such 
that V is substantial!)^ unpredictable by the third party. The protocol may include the first 
party, upon receiving I, verifying whether V satisfies the property P. The protocol may 
include the first party causing a fourth party to receive an amount A, only if V satisfies the 
property P. 

[0041 ] The micropayment selection protocol may establish-payment for a transaction T 
characterized in part by a time t. The protocol may include a first party deriving firom T a 
data string C related to T, such that C includes infomaation IN regarding the tinie t. The 
protocol may include the first party causing a second party to receive at least a portion of 
the data string C, such that the at least a portion of C includes information IN. The protocol 
may include the second party associating v/ith the at least a portion of C an item V, such 
that V is substantially unpredictable by the first party. The protocol may include the second 
party detemiining whether V satisfies a property P, and if so, the second party at time t' 
causing a third party to receive information IN and information I enabling the third party to 
verify whether V satisfies the property P. The protocol may include the third party, upon 
receiving I, verifying whether V satisfies the property P; and the third party causing a 
fourth party to receive an amount A, only if: V satisfies the property P, and |t' - 1| is less than 
a predetermined time interval. 

[0042] The micropayment selection protocol may establish payment for a transaction T. 
The protocol may include a first party deriving firom T a data string C related to T, and 
causing a second party to receive at least a portion of the data string C. The protocol may 
include the second party determining whether a property P holds between the at least a 
portion of C and a quantity Q depending on C, such that Q is substantially unpredictable by 
the first party, and if so, the second party causing a third party to receive information I 
enabling the third party to verify that the property P is satisfied. The protocol ma,y include 
the third party, upon receiving I, verifying whether the property P is satisfied, and only 
upon verifying that the property P holds between the at least a portion of C and Q, the third 
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party causing a fourth party to receive aii amount A. 

[0043] The micropayment selection protocol may establish payment for a transaction T 
characterized in part by a time t. The protocol may include a first party deriving from T a 
data string C related to T. The protocol may include a second party deriving a sequence of 
values VLi associated with a sequence of times tj (i = 1, . . . , n), such that for at least one 
integer m greater than 1 and less than n, |t - tm| is less than a predetermined amount. The 
protocol may include the first party causing the second party to receive at least a portion of 
the data string C, such that the portion includes information regarding the time t of the 
transaction T. The protocol may include the second party determining whether a property P 
holds between the portion of C, and one of the value VLm associated with tm, and a quantity 
Q depending on VLm. The protocol may include, if P holds, tlie second party causing a 
tliird party to receive infomiation I enabUng the third party to verify that the property P is 
satisfied. The protocol may include the third party, upon receiving I, verifying whether Q 
satisfies P. The protocol may include the third party causing a fourth party to receive an 
amount A, only if Q satisfies the property P. 

[0044] The micropayment selection protocol may establish payment for a transaction T 
characterized in part by a transaction t. The protocol may include a first party deriving 
from T a data string C related to T, such that C includes information regarding t. The 
protocol may include a second party deriving a sequence of values V,- associated with a 
sequence of time units ti (i = 1, . . . , n); such that each pair of adjacent time units tf-n and t,- 
defines a time interval At, = tj+i- ti; and such that for at least an integer m greater than 1 and 
less than n, the time t is within the time interval Atm- The protocol may include at the 
beginning of the time interval Atm, the second party deriving a value Qm associated with Vm, 
such that Qm is substantially unpredictable by the first party. The protocol may include 
durmg the time inten^al Atm: the first part}' causing the second party to receive at least a 
portion of C; the second party detemiining whether a property P holds betv^^een the portion 
of C and Qm, and if so, the second party causing a third party to receive information I 
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enabling the third party to verify that the property P is satisfied. . The protocol may include 
the third party, upon receiving I, verifying whether Q satisfies P. The protocol may include 
the third party causing a fourth party to receive an amount A, only if Q satisfies the 
property P. 

[0045] The micropayment selection protocol may estabUsh payment for a transaction T 
characterized in part by a time t. The protocol may include a first party deriving fi-om T a 
data string C related to T, such that C includes information F regarding t. The protocol may 
include a second party deriving a sequence of values Xj (i = 0, 1, . . . , n) associated with a 
sequence of time values ti (i = 0, 1, . . . , n), and making Xo public; such that x,* = H(xi+i) for 
i = 0, 1, . . . , n-1, where H is a one-rway hash function, such that each pair of adjacent time 
values ti+i and ti defines a time interval Atj = tj+i - ti; aad such that for at least an integer m 
greater than 1 and less than n, the time t is the time interval Atm. The protocol may include 
during the time interval Atm, the first party causing the second party to receive at least a 
portion of C, such that the portion includes R The protocol may include during the time 
interval Aim, the second party determining whether a property P holds between Qm and the 
portion of C, and if so, the second party causing a third party to receive information I 
enabling the third party to verify that tiie property P is satisfied. The protocol may include 
the third party, upon receiving I, verifying whether Qm satisfies P. The protocol may 
include the third party causing a fourth party to receive an amount A, only if Q satisfies the 
property P. 

[0046] The micropayment selection protocol may establish payment for a transaction T 
characterized in part by a time t. The protocol maj' include a first pMt>' receiving from a 
second party at time f information I enabling the first party to verify that an item V satisfies 
a propert>^ P, such that the item V is associated with at least a portion of a data string C that 
is derived firom T by a third party and that includes information regarding t, such that V is 
substantially unpredictable by the third party. The protocol may include the first party, 
upon receiving I, verifying whether V satisfies the property P; and C. The protocol may 
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include the first party causing a fourth party to receive an amomit A, only if: a) V satisfies 
the property P; and |t' - 1| is less than a predetermined amount. 

[0047] Tlie micropayment selection protocol may establish payment for a transaction T 
characterized in part by a time t. The protocol may include a first party receiving from a 
second party at least a portion of a data string C, such that the data string C is related to T, 
and such that the portion of C includes information on t. The protocol may include the first 
party associating with the at least a portion of C an item V, such that V is substantially 
unpredictable by the second party. The protocol may include the first party determining 
whether V satisfies a property P, and if so, tlie first party at a time t' causing a tliird party to 
receive information I enabling the third party to verify whether V satisfies the property P, 
thereby enabling the third party to cause a fourth party to receive an amount A, provided 
that V satisfies P; and 1 1' - 1 1 is less than a predetermined amount. 

[0048] The micropayment selection protocol may establish payment for a plurality of n 
transactions Ti, T2, . . . Ti, . . . Tn, such that an index i, between 1 and n, can be associated 
with each Ti, and such that each transaction Tj is characterized in part by a transaction value 
TVi. The protocol may include a first partj' using a probabilistic payment scheme to 
generate a check Ci for each transaction Ti and causing a second party to receive the Q, 
such that Ci includes an indication of the index i. The protocol may include the second 
party selecting the checks Cj (1 < j < n ) that are payable in a manner that prevents tlie first 
party firom predicting in advance which checks Q will be selected to be payable. The 
protocol may include the second party causing a third party to receive information Ij 
enabling the fliird party to verify that a selected check Q is payable. The protocol may 
include the third party, in response to receipt of Ij, verifying that a selected check Cj is 
payable; and only if Q is payable, a fifth party causing a fomth party to receive a credit 
amoiiht CRj, and causing the first part)' to be debited by a debit amount Dj so that, for all 
index j between 1 and n, and for any selection of payable checks, D=Di+D2+...+Dj is no 
greater than TVagg = TVi + TV2 + . . . -i-TVj. 
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[0049] The micropayment selection protocol may establish payment for a plurality of n 
transactions Ti, T2, . . . Ti, . . . Tn, such that an index i, betv^^een 1 and n, can be associated 
with each Tj, and such that each transaction Tj is characterized in part by a transaction value 
TVj. The protocol may include a first party deriving firom each transaction Ti a data string 
Ci related to Tj, and causing a second party to receive the data string Q. The protocol may 
include the second party associating with each data string C\ an item Y\, such that Vi is 
substantially unpredictable by the first party. The protocol may include the second party 
determining whether Vi satisfies a property Pi, and if so, the second party causing a tliird 
party to receive information li enabling the third party to verify whether Vi satisfies the 
property Pi; the third party, in response to receipt of Ij, verifying whether Vi satisfies the 
property Pf. The protocol may include, only if Vi satisfies the property Pi, a fifth party 
causing a fourth party to receive a credit amount CRi, and causing the first party to be 
debited by a debit amount Dj; such that the debit amount Di is less than or equal to the 
credit amount CRi. 

[0050] The micropayment selection protocol may pay for a plm-alitj^ of equal-valued 
transactions Ti, T2, . . . Ti, . , . Tn, each having a value TV The protocol may include a first 
party deriving firom each transaction Ti a data string Q related to Ti, and causing a second 
party to receive the data string Q, such that each data string Q comprises a progressive 
serial number Si, the serial number Si being sequentially ordered starting firom 1 and being 
representative of a position of Ci relative to other data strings in an ordered succession of 
data strings Cj 0 = 1> • • • > ^i)- The protocol may include the second party associating with 
Ci an item Vj, such that Vi is substantially unpredictable by the fiarst party. The protocol 
may include the second party determining whether a property' Pi holds betv^^een Cj and Vj, 
and if so^ the second party causing a third party to receive information li enabling the third 
party to verify' whether Vi satisfies Pj; D. The protocol may include the third party 
verifying whether Vi satisfies Pj; and only if Vi satisfies Pi: a fifth party determining the 
value of Smax, such that Smax represents the largest of any serial nimiber Sk contained in Ck 
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for which: 1 ^ < n; Ck is received by second party before receiving Cj. The third party has 
verified that Vk satisfies Pk and the first party has been debited by a nonzero amount Dk, the 
fifth party causing a fourth party to receive a credit amount CR. The protocol may include 

the fifth party causing the first party to be debited by a debit amount Di, where Di is given 

i> 

by:(Si-S™x) * TV. 

[0051] The micropayment selection protocol may allow a user to estabUsh payment to 
a merchant M for a plurality of transactions Ti (i = 1, . . . , n) having transaction values TVj 
(i = 1, . . . , n). The protocol may include the user U establishing a public key and a 
corresponding secret key for a first digital signature scheme, and deriving firom each Tj a 
data string Ci = SIGu(Ti) and creating an electronic check CHj that contains Q and a serial 
number Si, such that SIGu(Ti) represents the digital signature of the user Ui for the 
transaction Ti in the first digital signature scheme, such that Si is a progressive serial 
number representative of an order of the data string Q relative to the other data strings in an 
ordered succession of data strings Q G = 1, . . . , n) derived by the first party. The protocol 
may include the user U causing the merchant M to receive the electronic check CHi 
containing Q and Si. The protocol may include the merchant M establishing a public key 
and a corresponding secret key for a second digital signature scheme, and associating with 
the data string Q an item Vi = SIGmCQ), such that SIGM(Ci) represents the digital signature 
of the merchant M for the data string Ci in the second digital signature scheme. The 
protocol may include the merchant M computing the value F(Vi)=F(SIGM(Ci)), where F 
represents a public function that operates on a bit string to output a number between 0 and 
1 . The protocol may include the merchant M comparing F(SIGTvi(Ci)) with a constant s (0 < 
s < 1) to determine whether F(Vi) < s, and if so, causing a bank to obtain the public key of 
the merchant M. The protocol may include the bank using the merchant's public key to 
verify that FCSIGmCQ)) <s; and only if FCSIGmCQ)) < s, a fifth part>' determining the value 
of Smax, such that Smax represents the largest serial number Sj contained in any CHj in the 
ordered succession upon which payment was made. The protocol may include die fifth 
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party causing a fourth party to receive a credit amount CR. The protocol may include the 
fifth party causing the first party to be debited by a debit amoxmt Dj, 

[0052] The micropayment selection protocol may establish payment for a plurality of n 
transactions Ti, T2, . . . , Ti, . . . , Tn, such that an index i, between 1 and n, can be associated 
with each Ti, and such that each transaction Ti is characterized in part by a transaction value 
TV,-. The protocol may include a first party receiving from a second party at least a portion 
of a data string Ci for each Ti, such that each data string Ci is generated firom Ti using a 
probabilistic payment scheme, and such that each Ci includes an indication of the index i. 
The protocol may include the first party selecting the checks Cj 0 less than or equal to n 
and greater than or equal to 1) that are payable in a manner that prevents the first party from 
predicting in advance which checks Cj Avill be selected as payable. The protocol may 
include, for each selected check Cj, the first party causing a third party to receive 
information Ij enabling the third party to verify that the selected check Cj is indeed payable, 
thereby enabling the third party, upon verification that Cj is payable, to cause a fourth party 
to receive a credit amount CRj and the second party to be debited by a debit amoimt Dj so 
that, for all index j between 1 and n, and for any selection of payable checks Cj, D = Di + 
D2 + . . . Dj is no greater than T Vagg = TVi + TV2 + . . . + TVj . 

[0053] The micropajonent selection protocol may establish payment for a plurality of n 
transactions Ti, T2, /. . , Tj, . . . , Tn, such that an index i, between 1 and n, can be associated 
with each Ti, and such that each transaction Ti is characterized in part by a transaction value 
TVi and can be represented by a corresponding data string Ci. The protocol may include a 
first party receiving from a second party information I, enabling the first party to verify that 
a check Cj is payable, such that the check Cj is selected by the second party from sl plurality 
of checks Ci (i = 1, . . , , n) derived by a third part}^ from a corresponding one of the pluralit3' 
of tr^sactions Ti (i = 1, . . . , n), such that the selection of the check Cj is substantially 
unpredictable by the third party. The protocol may include the first party, upon receiving Ij, 
verifying whether Cj is indeed payable. The protocol may include the first party causing a 
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fourth party to receive a credit amount CRj, and causing the third party to be debited by a 
debit amount Di, 

[0054] The micropayment selection protocol may establish payment for a plurality of n 
transactions Ti, T2, . . . Ti, . . . Tn, such that eac^i transaction Ti is characterized in part by a 
transaction value TVj that is a multiple of a unit value UV. The protocol may include a fii*st 
party deriving from each transaction Ti a data string Ci corresponding to Ti, and causing a 
second party to receive C\, such that each data stiing Cj includes information on the integer 
index i and the value TVi of Ti in the form of a vector (Si, Si + Vj-l), such that for all i 
between 1 and n, Sj is a progressive serial number that is sequentially ordered and that is 
representative of a position of Ci relative to other data strings in an ordered succession of 
data strings Q (j = 1, - . . , n), and such that Vi is an integer dependiag on i and indicative of 
the value TVi of Ti, and is given by Vi = TVj / (UV). The protocol may include the second 
party selecting the checks Cj (1 < j < n ) that are payable in a manner that prevents the first 
party from predicting in advance which checks Cj will be selected to be payable. The 
protocol may include the second party causing a third party to receive information Ij 
enabling the third party to verify that a selected check Q is payable. The protocol may 
include the third party, in response to receipt of Ij, verifying that a selected check Q is 
payable. The protocol may include, only if Q is payable, a fifth party determining the 
value of Sniax, such that max is an integer such that 1 < max < i < n, and Vxnax = TV^ax / (UV), 
and such that Smax represents the largest of any serial number Sk (1 ^ k < n) contained in Ck 
for which: Ck is received by the second party before receiving Q; and the third party has 
verified that Vk satisfies Pk; and the first party was debited by a non-zero amount Die, and 
the fifth party causmg a fourth party to receive a credit amount CR, The protocol may 
include the fifth party causing the first party to be debited by a debit amount Di, where Di is 
given by: ( Si + Vi - 1 - Smax ) * UV. 

[0055] The micropayment selection protocol may establish payment for a plurality of n 
transactions Ti, T2, . . . Ti, . . , Tn, such that an index i between 1 and n is associated v^th 
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each Ti, and such that each transaction Tj is characterized in part by a transaction value TVi 
that is an integral multiple of a unit value UV. The protocol may include a first party 
deriving Jfrom. each transaction Ti a data string Ci coixesponding to Ti and causing a second 
party to receive Ci, such that each data string C,- includes information on the integer index i 
and the value TVi of Tj in the form of a vector (Si, Si + Vi - 1), such that for all i between 1 
and n. Si is a progressive serial nimiber that is sequentially ordered and that is 
representative of a position of Ci relative to other data strings in an ordered succession of 
data strings Cj (j = 1, . . . , n), and such that Vi is an integer depending on i and indicative of 
the value TVi of Tj, and is given by Vj == TVf / (UV). The protocol may include the second 
party associating with Cj an item Vi, such that Vj is substantially unpredictable by the first 
party. The protocol may include the second party determining whether a property Pi holds 
between Ci and V,, and if so, the second paity causing a third party to receive information li 
enabling the third party to verify whether Vi satisfies Pi. The protocol may include the third 
part>' verifying whether Vi satisfies Pj; and only if Vj satisfies Pj: a fifih party determining 
the value of Smax? such that max is an integer such that 1 < max < i < n, and Vmax = TVmax / 
(UV), and such that Smax represents the largest of any serial number Sjc (1 < k < n) contained 
in Ck for which: Ck is received by the second party before receiving Q; and the third party 
has verified that Vk satisfies Pk; and the first party was debited by a non-zero amount Dk. 
and the fifth party causing a fourth party to receive a credit amount CR; and c)the fifth 
party causing the first party to be debited by a debit amoimt Dj, where Di is given by: ( Si + 
Vi-l-S„^)*UV 

[0056] The micropayment selection protocol may establish payment for a plurality of n 
transactions Ti (i = 1, . . . , n), each transaction Tj having a value TVi. The protocol may 
include a first party deriving firom each Tj a data string Q related to Ti, and causing a 
secohd party to receive the data string Ci; The protocol may include the second party 
uniquelj' associating groups of the data strings Ci (i = 1, . . . , n) into m hsts L\ where k = 
1, . . . , m; such that each list includes data strings C^i, . . . , C^h, and such that S\ = i 
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= n; the second party coimnitting to (k = 1, . . . , m), by computing a commitment CM 
for each L^ and caiising a third party to receive CM'' (k = 1, . . , m); the third party, in 
response to receipt of CM^' (k = 1, . . . , m), selecting one or more integer indices ii, i2, . . • ir, 
and causing the second party to receive the indices ii, i2, . . . ir, such that I <'ir < m; in 
response to receipt of the indices ii, ia, . . . ir, the second party de-committing CM'\ CM'^. . . 
CM'', thereby revealing V\ . . L''" to the third party; and a fifth party causing a fourth 
party to receive a credit amount CR, and causing the first party to be debited by a debit 
amount D. 

[0057] The micropayment selection protocol may estabUsh payment for a plurality of n 
transactions Ti, . . . , Tj, . . . , Tn, each transaction Ti having a value TVi. The protocol may 
include, for each Ti, a first party receiving firom a second party a data string Ci derived firom 
Ti. The protocol may include the first party uniquely associating groups of the data strings 
(i = 1, . . . , n) into m hsts L^, where k = 1, . . . , m, such that each list L^' includes data 
strings C^i, . . . , C\, and such that I.\ 1 4 = n. The protocol may include the first party 
committing to (k = 1, . . . , m), by computing a commitment CM^ for each L^ and 
causing a third party to receive CM^ (k = 1, . . . , m), thereby enabling the third party to 
select one or more integer indices ii, ia, ^ . • ir, such that 1 < ir < m; upon receipt of the indices 
ii, i2, . . . ir, the first party de-committing CM'\ CM^^. . . CM^ thereby revealing . . 
to the third party and enabling the third party to cause a fourth party to receive a credit 
amount CR, and the second party to be debited by a debit amount D. 

[0058] The micropaionent selection protocol may establish payment for a plurality of n 
transactions Ti, . . . , Ti, . . . , T„, such that each transaction Ti has a value TVi and can be 
represented by a corresponding data string Ci derived from Ti, and such that groups of the 
data strings Q (i = 1, . . . , n) can be uniquely associated into m lists L^^ (k = 1, . . . , m), each 
list t^' includes data strings C\, . . . , C\ i Ac = li). The protocol may include a first 
party receiving from a second party a commitment CM^ for each of the m lists Lk (k = 
1, . . . , m). The protocol may include the first party, upon receiving CM^ (k = 1, . . . , m). 
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selecting one or more integer indices ii, ii, . . . ir, such that 1 < if $ m, and causing the second 
party to receive the indices ii, ii, . . . ir, thereby enabling the second party to de-commit 
CM'\ CM^. . . CM'^ so as to revealing L'^ . . L'' to the first party. The protocol may 
include the first party causing a third party to receive a credit amount CR, and a fourth 
party to be debited by a debit amoimt D. 

[0059] The above-described methods may also be implemented as a sequence of 
instructions executed by a processor. 

[0060] The details of one or more implementations is set forth in the accompauying 
drawings and the description below. Other features and advantages will become apparent 
firom the description, the drawings, and the claims. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a diagrammatic view of micropayment processing system coupled to a 
distributed computing network; 

FIG. 2 is a more-detailed diagrammatic view of the micropayment processing 
system of FIG. 1; 

FIG. 3 is a block diagram of an offer development module of the micropayment 
processing system of FIG. 1; 

FIG. 4 is a block diagram of a consumer agent module of the micropayment 
processing system of FIG. 1; 

FIG. 5 is a diagraimnatic view of display screen rendered by the micropayment 
processing system of FIG. 1; 

FIG. 6 is a block diagram of a PCS module of the micropajTOent processing system 
of FIG. 1; 

FIG. 7 is a block diagram of a mPSP module of the micropayment processing 
system, of FIG. 1; 
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FIG. 8 is a block diagram of a cPSP module of the micropayment processing 
system of FIG. 1; 

FIG. 9 is a block diagram of a batch processing module of the micropayment 

processing system of FIG. 1; 

FIG. 10 is a diagranrmiatic view of an encoded batch file; and 

FIG. 11 is a block diagram of a verification module of the micropayment 

processing system of FIG. 1; 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

[0061] Referring to FIG. 1, there is shown a micropayment processing system 10 that 
processes various micropayments tokens (i.e., a token representative of low-value 
payments) 12, 14, 16 received by a merchant 18 for various products/sendees 20, 22, 24 
offered by merchant 1 8. 

[0062] Micropayment processing system 10 tj'pically resides on and is executed by a 
computer 26 that is connected to network 28. Computer 26 may be a web server running a 
network operating system, such as Microsoft Window 2000 Server Novell Netware 
or Redhat Linux Typically, computer 26 also executes a web server application, such as 
Microsoft nS ^, Novell Webserver or Apache Webserver ^, tiiat allows for HTTP (i.e., 
HyperText Transfer Protocol) access to computer 26 via network 28. 

[0063] The instruction sets and subroutines of micropajonent processing sj'stem 10, 
which are typically stored on a storage device 30 coupled to computer 26, are executed by 
one or more processors (not shown) and one or more memory architectures (not shown) 
incorporated into computer 26. Storage device 30 may be, for example, a hard disk drive, a 
tape drive, an optical drive, a RAID array, a random access memor>' (RAM), or a read-only 
memory (ROM). 
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[0064] As will be discussed below in greater detail, one or more consumers 32, 34, 36 
access and use various portions of micropayment processing system 10 (via consumer 
computers 38, 40, 42, respectively) to receive and review offer packages 44, 46, 48 
concerning products/services 20, 22, 24 offered for sale by merchant 18, who accesses 
micropayment processing system 10 via merchant computer 50. 

[0065] Referring also to FIG. 2, micropayment processing system 10 includes: an offer 
development module 100, a consumer agent module 102, a payment collection service 
(PCS) module 104, a merchant paj/ment service provider (mPSP) module 106 (which 
interfaces with a merchant banking institution 108); and a consumer payment service 
provider (cPSP) module 110 (which interfaces with a consumer baiiking institution 1 12), 
each of which will be discussed below in greater detail. 

[0066] Referring also to FIG. 3, offer development module 100 allows merchant 18 to 
prepare 150 offer packages (e.g., offer packages 44, 46, 48) for distribution and solicitation 
to potential consumers. 

[0067] When using offer development module 100, new merchants are required 152 to 
estabUsh a merchant account prior to being able to prepare offer packages. Specifically, 
offer development module 100 allows a new merchant to access mPSP module 106 (to be 
discussed below in greater detail) and estabUsh such a new merchant account 

[0068] When establishing a new merchant account, the new merchant provides 154 
mPSP module 106 with information, such as: merchant name; merchant address; merchant 
usemame; merchant password; merchant email address; merchant telephone number; and 
merchant banking institution 108 (i.e., for defining the account(s) into which received 
funds axe to be deposited). 

[0069] As stated above, offer packages 44, 46, 48 pertain to various products/services 
that are offered for sale by merchant 1 8. Examples of these products/ser\dces may include 
an individual song encoded in a easily-transmittable format (such as an MP3 format), a 
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streaming video broadcast of a concert, a streaming audio broadcast of a sporting event, 
and participation in an online video game for a defined period of time, for example. 

[0070] The merchant uses offer development module 100 to define 156 an offer 
package for solicitation, such that the offer package typically indludes a description of 
what is being offered (e.g., the latest release of song "X'' by artist "Y"), and the cost of the 
offer package (e.g., $0.10). Additionally, the duration of what the consumer is offered is 
also defined. For example, the merchant may offer the product/service: (a) for an . 
unlimited number of uses over an xmlimited period of time, (b) for an imlimited number of 
uses over a limited period of time, (c) for a hmited number of uses over an unlimited period 
of time, or (d) for a limited number of uses over a limited period of time, each of which 
impacts the cost of the product/service. 

[0071] The offer package typically also defines: the merchant that is making the offer; 
the address or URL (i.e., uniform resource locator) of the PCS module 104 that will be 
processing the xnicropayment token; and the currency of the offer (e.g., U.S. dollars, 
European Euros, Japanese Yen, or British Pounds, for example). An expiration date 
concerning the offer (if applicable) may be included in the offer package for time sensitive 
events, such as those concerning promotional periods or the live broadcast of public events. 

[0072] An encrypted copy of the product/service offered for purchase may be included 
158 in the offerpackage (e.g., off^ packages 44, 46, 48). For example, if the offerpackage 
concerns an individual song, the offer package prepared by the merchant may iuclude the 
actual song offered for purchase. However, as will be discussed below in greater detail, the 
song is encrj'pted 160 prior to incorporation so that the consumer does not have access until 
the consumer accepts the offer and pays the merchant for the song. This type of offer is 
beneficial for product-based offers (e.g., an offer to purchase a song), as the offer cannot be 
accepted until after the offer package is downloaded. And, once the offer package is 
successfully downloaded, the offered product (i.e., the song) is abready on the computer 
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operated by the consumer. This, in turn, reduces the likelihood of a consumer claiming that 
they purchased a product that they were not able to retrieve (i.e., download). 

[0073] Alternatively, an URL that provides a link to a website from which the 
product/service can be obtained may be encrypted 162 and included 164 in the offer 
package. Since this URL is encrypted, the URL is not useable until after the consumer 
accepts the offer and the merchant is paid for the product/service. This type of offer is 
beneficial for events that will occur in the future and for products not currently available 
(e.g., a streaming broadcast of the Superbowl and a song from an album that has not yet 
been released, for example). 

[0074] Once merchant 18 defines an offer package, prior to offering 166 the offer 
package to the consumer, the offer package is digitally signed 168 by the merchant using a 
merchant digital certificate (hereinafter mCERT), which is typically received 1 70 from the 
mPSP module 106 (to be discussed below in greater detail) and authenticates the integrity 
of the offer package. The mCERT may be stored locally or retrieved from a remote 
computer (e.g., computer 26). 

[0075] The mCERT is a file that establishes the credentials of the merchant. The 
mCERT typically contains the merchant's name, a unique merchant serial number (for 
identification purposes), a certificate expiration date, a copy of the merchant's public key 
(for encrypting messages and digital signatures), and the digital signature of the 
certificate-issuing authority (e.g., Avww.verisign.com or a third-party trust agent) so that 
a consumer can verify the integrity of the merchant digital certificate. 

[0076] Typically, when using an mCERT, prior to making the offer package available 
to the consumer, a hashing algorithm generates a hash of the offer package, wherein the 
hash is essentially a mathematical summary of the offer package. The merchant then 
encrypts this hash using the private key of the merchant's private-public encryption key 
pair. This encrypted hash functions as tlie merchant's digital signature. When the 
consumer is verifytag the integrity of the offer package, the consumer makes a hash of the 
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offer package using the same hashing algorithm that the merchant used to make their hash. 
The consumer then uses the merchant's publicly-available public key to decrypt the digital 
signature (i.e., the hash made by the merchant) and the two hashes are compared.. If the 
two hashes match, the integrity and authenticity jof the offer package is confirmed. 

[0077] Typically, a merchant (e.g., merchant 18) will simultaneously present to the 
potential customer multiple offer packages. For example, if tlie merchant is a music 
distribution website, the consumer may execute searches based on song title, album title, 
artist name, release date, or music type, for example. This, in turn, generates a results list 
that includes a URL to each of the results (i.e., offer packages) included in the results list. 
These offer packages hiay concern individual songs, compilations of songs, entire albums, 
or entire musical anthologies. 

[0078] Offer development module 100 is typically a web-enabled apphcation that is 
accessed by tlie merchant (e.g., merchant 18) tlirough a browser application (e.g., 
Microsoft Intemet Explorer ^, or Netscape Navigator ^) that is running on merchant 
computer 50, and the merchant logs into naicropayment processing system 10 using an 
encrypted SSL (i.e., secure sockets layer) connection. Alternatively, offer development 
module 100 may be a local application that is executed locally on merchant computer 50. 

[0079] Referring also to FIG. 4, consumer agent module 102 allows the consumer to 
review 200 offer packages (e.g., offer packages 44, 46, 48) generated by merchant 18, and 
accept (i.e., purchase the product/service) 202 those offer packages m which the consumer 
is interested. Additionally, consumer agent module 102 verifies 204 the integrity of the 
offer package received from the merchant by making a hash of the offer package using the 
same hashing algorithm that the merchant used to make their hash of the offer package. 
The consumer agent module 102 then uses the merchant's pubhcly-available public key to 
decrypt the hash made by the merchant, and the decrypted merchant's hash and the 
consmner's hash are compared. If these two hashes match, the integrity and authenticity of 
the offer package is confirmed. 
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[0080] Typically, consximer agent module 102 is a web-enabled application that is 
accessed by the consumer (e.g., consumer 32) through a browser application that is running 
on a consumer computer (e.g., consumer computer 38), and the consumer securely logs 
into micropayment processing system 10 using an encrypted SSL* connection. 
Alternatively, consumer agent module 102 may be a local application that is * executed 
locally on a consumer computer 38. 

[0081] Wlien using consumer agent module 102, new users are required 206 to 
establish a consumer account prior to being able to accept offers and purchase the 
products/services being offered for sale by the merchant. Through the use of consumer 
agent module 102, a consumer can access cPSP module 110 (to be discussed below in 
greater detail) to establish such a new consumer account. 

[0082] When establishing a consumer account, the new consumer provides 208 cPSP 
module 110 with information, such as: consumer name; consumer billing address; 
consumer usemame; consumer password; consumer email address; consumer telephone 
number; consumer credit card information (for billing purposes, thus defining the 
consumer banking iostitution 1 12 against which charges should be appUed); and consumer 
age (for content regulation and access purposes), for example. Additionally, the consumer 
may define 210 the type of accotmt, such as "prepaj^' or postpa/'. 

[0083] For prepay accounts, the consumer uses, for example, a credit card to transfer 
funds into the consumer account, and when using the account, the consumer is only 
permitted to purchase products/services if the balance in their consumer account is 
sufficient to cover the cost of the products/services sought. In the event that the account 
has insufficient funds to cover the purchase, the purchase is denied. This tj'pe of account is 
beneficial when, e.g., a parent wishes to control the spending of their teenage child. 

[0084] Alternatively, the consumer accoimt may be configured as a "postpay" account 
and, therefore, no prerequisite funds are required prior to allowing the consumer to make 
the purchase. However, a "credit limit" may be defined for a "postpay" accoimt, such that 
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the consumer can only purchase products/services up to a certain amount, above which the 
charges will be denied. 

[0085] .Once a consumer estabhshes a consumer account using consumer agent module 
102, the consumer may accept 202 offers and, therefore, purchase products/services 
offered by the merchant. 

[0086] As consumer agent module 102 allows a consumer to purchase the 
products/services offered for sale by the merchant, when using consumer agent module 
102, the consumer is required to authenticate 212 their identity. This authentication may 
be accomplished by having the consumer enter their usemame and password combination, 
or through any other known means of identity authentication (e.g., token, certificate, or 
cookie passing). 

[0087] Once the consumer's identity is authenticated, a consumer digital certificate 
(hereinafter cCERT) concerning the consumer using the consumer agent module 102 is 
retrieved 214 firom cPSP module 110. Similar in nature to the mCERT, the cCERT 
typically contains the consumer's name, a unique consumer serial number (for 
identification purposes), a certificate expiration date, a copy of the consumer's public key 
(used for encryptmg messages and digital signatures), and the digital signature of tlie 
certificate-issuing authority so that a merchaat can verify the integrity of the consumer 
digital certificate. Typically, the unique consumer serial number allows for determination 
of the cumulative spending amount (to be discussed below) of the consumer to which the 
digital certificate pertains. Additional^, the cCERT may also define the status of the 
consumer's account (e.g., active, suspended or revoked, for example), and the tj'pe of 
consumer account (e.g. , "prepay" or "postpa/' account, for example). 

[0088] When a consumer is re\aewmg 200 an offer tlirough the browser application, 
the consumer agent module 102 is typically automatically launched in response to a 
consumer selecting an offer package for review, thus allowing the consumer to review the 
details of the offer package. Tliis selection of an offer package for review is t5'pically 
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accomplished by the consumer "clicking" on the ofifer package or a link pointing to the 
offer package. 

[0089] Referring also to FIG. 5, when reviewing 200 an offer package, consumer agent 
module 102 renders 216 a user interface display screen 250 that displays the details of the 
offer to the consumer, such as the artist and song title 252, the cost of the offer 254, the 
payee 256, the expiration date 258, and an overall description 260. 

[0090] If, upon reviewing 200 an offer package, the consumer decides to accept 202 
the offer and purchase the product/service offered by the merchant, tlae consumer executes 
an affirmative action to initiate the purchase, such as "clicking" on the buy button 262 with 
a mouse pointer 264 (or some other pointing device, not shown). 

[0091] When the purchase is initiated, consumer agent module 102 examines 218 the 
cCERT to confimi that the consumer is not suspended. Further, if the consumer accoimt is 
a prepay accoimt, the consumer agent module verifies 220 that the balance in the consxmier 
account is sufficient to cover the cost of the product/service sought. 

[0092] Accordingly, if the consumer is an active (i.e., non-suspended) consumer and 
the account is either a postpay account or a sufficiently-funded prepay account, a 
micropayment token (e.g., token 12, 14, 16) is generated 222 for effectuating the purchase 
of the products/services offered by the merchant The micropayment token is digitally 
signed 224 using the consumer's digital signature included in the cCERT retrieved by the 
consumer agent module 52. The ndicropayment token, which is transmitted 226 to PCS 
module 104, defines flie product/ser\dce being purchased, defines the micropajment token 
amount (i.e., the amount of the purchase), identifies the consumer making the purchase, 
and defines the cumulative spend amount of that particular consumer. This cumulative 
spend amount, which is tj'pically retrieved from the cPSP module 110 using the consumer 
serial number included within the cCERT, defmes the total amount of monies previously 
spent by that consumer on products /services, and does not include the cost associated with 
the offer currently being accepted. 
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[0093] Referring also to FIG. 6, when the PCS module 104 receives 300 a 
micropayment token, the micropayment token is typically validated 302 to make sure that 
it is authentic and has not been tampered with. As stated above, the micropayment token 
transmitted by the consuiner agent module 102 is digitally signed 224 using the digital 
signature of the cCERT. Therefore, a hash is made of the micropayment token and the 
hash is encrypted using the private encryption key of the consumer's private/public 
encryption key pair. 

[0094] Accordingly, when validating the micropayment token, PCS module 104 
makes a hash of the micropayment token using the same hashing algorithm that the 
consumer used to make their hash. The PCS module 104 then uses the consumer's public 
encryption key to decrypt the hash made by the consumer agent module and the two hashes 
are compared. If the two hashes match, tlie integrity and authenticity of the micropayment 
token is confirmed. 

[0095] The token vahdation process 302 exercised by PCS module 104 typically also 
includes verifying that the cimiulative spend amount specified in the micropayment token 
matches the cumulative spend amount specified in the cCERT. 

[0096] PCS module 104 may also validate 304 the offer package (through the use of 
the merchant's digital signature and pubUc encryption key include in the mCERT) to 
ensure the integrity of the offer package. This offer validation process 304 typically also 
includes: verifying that the offer package is still valid (e.g., was not withdrawn by the 
merchant, or did not expire, for example); and examining the offer package requirements 
to verify that the consumer meets any such requirements. For example, a 15 year old 
consumer would not be allowed to accept an offer package concerning the viewing of an 
MC-17 rated movie. 

[0097] Once validated 302, 304, the micropayment token is accepted 306 by PCS 
module 104 and queued 308 for processing. Additionally, PCS module 104 generates 310 
a content receipt 52 that is transmitted 3 12 to the consumer agent module 102 and typically 
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includes a decryption key that allows the consumer to acpess the products/services 
purchased. Further, PCS module 104 also updates 314 (i.e., increments) the differential 
amount (to be discussed below) of the consumer's cumulative spend amount by the 
micropayment token amount. 

[0098] As stated above, an offer package generated by the merchant may include an 
encrypted version of the actual data file (e.g., an MP3-based song. file). If the consumer 
accepts such an offer, the data file purchased is already resident on the consumer's 
computer (e.g., computer 38). In this scenario, the receipt 228 of the content receipt 52 
may trigger the consumer agent module 102 to decrypt 230 the data file resident on the 
consumer computer using the decryption key included in content receipt 52. 

[0099] Alternatively and as discussed above, the offer package prepared by the 
merchant may only include a link to an encrypted data file which is resident on a remote 
computer (e.g., computer 26). In this scenario, the receipt 228 of the content receipt 52 
(which includes a decryption key) may trigger the retrieval 232 of the encrypted data file 
(fironi the remote computer) prior to the decryption 230 of the encrypted data file. 

[00100] Additionally and as discussed above, the offer package prepared by the 
merchant may only include an encrypted link to an encrypted data file which is resident on 
a remote computer (e.g., computer 26). In this scenario, the receipt 228 of the content 
receipt 52 may trigger the decryption 234 of the encrypted link, prior to the retrieval 232 
and decryption 230 of the encrypted data file. 

[00101] Further and as stated above, the consumer may be purchasing access to an 
audio, video, or audio/video stream for an event that is happening in the fiiture. In this 
scenario, the decryption key included in the content receipt may be time-stamped and, 
therefore, not allow the consumer to access the stream mitil a time proximate the event. 
Additionally, the content receipt and/or the decryption key included in the content receipt 
may only be valid for a defined period of time. For example, the consumer may purchase 
one hour of access to an online gaming website. In such a scenario, the decryption key 
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and/or content receipt may only be valid for a chronological hour or, alternatively, one 
hour of online time. 

[00102] PCS module 104 executes the micropayment selection protocol 1 14, which is 
the subject of U.S. Patent AppUcation No.: 10/476,128, filed 27 October 2003, entitled 
"Method and System for Micropayment Transactions", which claims the benefit of priority 
to Intemational Application No.: PCT/US02/121S9 (filed 17 April 2002), which claims the 
benefit of priority to U.S. Provisional AppUcation 60/287,251 (filed 27 April 2001), U.S. 
Provisional Application 60/306,257 (filed 18 July 2001), and U.S. Provisional Application 
60/344,205 (filed 26 December 2001), which is herein incorporated by reference. A copy 
of Intemational Application No.: PCT/US02/12189 is attached hereto as Appendix A, 

[00103] As thoroughly disclosed in U.S. Patent Application No.: 10/476,128, 
micropayment selection protocol 114 processes micropayment tokens in a probabilistic 
fashion that is secure, random, and non-controllable by the consumer, merchant, or PSP 
module. Specifically, a defined percentage of micropayment tokens are selected 316 for 
processing, and the value of the micropayment token is increased (i.e., scaled by the 
inverse of the defined percentage) 3 1 8 so that a macropayment can be made to merchant 18. 
For example, assume that the defined percentage is 1% (i.e., 1 in 100) and, therefore, one 
out of every one himdred micropayment tokens is selected for processing. Accordmgly, a 
macropayment is made to the merchant that is scaled upward in accordance with the 
selection ratio. Therefore, if the value of flie selected micropayment token is $0.99 and the 
selection ratio is one in one hundred, the value of the macropayment made to the merchant 
is $99.90 (i.e., one hundred times the actual value of the micropayment token). 

[00104] Concerning the non-selected micropayment tokens (i.e., ninety-nine out of 
one hundred in this example), merchant 1 8 never receives payment for these micropayment 
tokens, as the single macropayment represents the probabilistic equivalent of the sum of 
these ninety-nine, non-selected micropayment tokens and the one selected micropayment 
token. 
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[00105] When a micropayment token is selected for processing by micropayment 
selection protocol 1 14 and is used as the basis for paying a macropayment to merchant 18, 
as stated above, the value of the naicropayment token is increased 318 to the appropriate 
macropayment level. The micropayment token is then digitally signed 320 by PCS module 
104 and then transmitted 322 to mPSP module 106 for processing. 

[00106] Referring also to FIGS. 7 and 8, mPSP module 106 is a payment service 
provider that is acting on behalf of merchant 18. Wlien mPSP module 1 06 receives 350 the 
micropayment token from PCS module 104, the validity of the micropayment token is 
verified 352. 

[00107] As disclosed above, the micropayment token is typically digitally signed 320 
by PCS module 104 prior to being transmitted 322 to the mPSP module 106. Accordingly, 
when the micropayment token is received 350 by mPSP module 106, mPSP module 106 
validates 352 the micropayment token by generating a hash of the micropayment token, 
decrypting the encrypted hash generated by the PCS module 104, and comparing the two 
hashes. If there is a match, the validity of the micropayment token is verified. 

[00108] Once the micropayment token is vahdated 352 by the mPSP module, the 
micropayment token is transmitted 354 to cPSP module 110 for further processing. As 
mPSP module 106 is acting on behalf Of merchant 18 and cPSP module 110 is acting on 
behalf of the consumer, mPSP module 106 will typically digitally sign 356 ttie 
micropayment token prior to transmission 3 54. The cPSP module 110 will typically verify 
400 the validity of the micropayment token upon receipt 402 (using the above-described 
procedures) and prior to acceptance 404. Once validated 400 and accepted 404, the 
micropayment token is queued (to be discussed below) for processing by cPSP module 
110. 

[00109] The queuing of micropaj/ment tokens reduces the risk of sj^stem illiquidity 
and merchant/consumer collusion. As disclosed above, each selected micropayment token 
(i.e., a token selected for macropayment processing) that is processed by cPSP module 110 
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specifies the cost of the offer d (i.e., the micropayment token amount), a stepped-up 
macropayment amount D (i.e., the offer cost multipHed by a scaling factor), and a 
cumulative spend amount Cj + C/ 

[001 10] For example, assume that the consumer repeatedly makes purchases that have 
a micropayment token amount d of $0.10. Further, as micropayment selection protocol 
114 processes micropayment tokens in a probabilistic fashion in accordance with a defined 
percentage or ratio, assume that the first seventy-five times that the consumer made tliis 
purchase, the consumer's micropayment token was not selected and, therefore, the 
consumer was never billed for their purchases. Accordingly, when the consumer makes 
their seventy-sixth purchase, the cumulative spend amount Cj + C/ specified in the 
micropayment token is $7.50, such that Cj (i.e., the last amount previously billed to the 
consumer) is equal to $0.00 (as the consumer has never been billed for any of their 
previous seventy-five purchases) and Cj (i.e., the differential amount that the consmner has 
spent since the last billing) is equal to $7.50, which represents the cost of the previous 
seventy-five unbilled purchases. 

[001 1 1] Queues maintained by cPSP module 110 consists of a queue reserve Qr and 
an ordered set of pending (i.e., yet-to-be-processed) micropayment tokens (e.g., tokens 12, 
14, 16). As cPSP module 110 receives 402, validates 400, and accepts 404 the 
micropayment tokens, cPSP module 1 10 bills 406 the consumer banking institution 1 12 for 
the differential amount spent (C/) plus the micropayment token amount d. Since, in this 
particular example, the consumer has never been billed, this differential amount is $7.50 
and the niicropa>'ment token amount is $0.10. Therefore, cPSP module 110 bills 406 
consumer banking institution 1 12 for $7.60, which is deposited 4 08 into queue reserve Qr. 

[001 12] The cPSP module 1 10 then inserts 410 the selected micropayment token into 
the back of the queue, wliich is typically a first-in-first-out (FIFO) queue. A FIFO queue is 
a queue in which the oldest entr}^ is serviced first and, conversely, the newest entry is 
serviced last. The cPSP module 110 repeatedly compares 412 the macropayment amount 
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D of the stepped-up micropayment token that is next in line for processing (i.e., the token 
that is at the front of the queue) to the current balance of the queue reserve Qr . Only when 
the current balance of the queue reserve Qr (which is currently at $7.60) is greater than or 
equal to the macropayment amount D of the micropayment token being examined (which 
in this example is $10.00) will the stepped-up micropayment token be processed and the 
macropajonent paid to the merchant. 

[001 13] As queue reserve Or is cuixently less than the macropayment amount D, the 
macropayment will not be made to the merchant. However, as the differential value of 
each subsequently-received micropayment token (that is vahdated by cPSP module 1 10) is 
deposited into the queue reserve Qr, eventually the value of queue reserve Or will be 
greater than or equal to the value of the macropajTOent amount D, When this occurs, the 
macropayment is issued 414 to the merchant banking institution 108 (via mPSP module 
106) and the value of the macropajonent is deducted 416 from queue reserve Qr. 

[00114] This process is repeated for each micropayment token that is at the fr ont of the 
queue until either: (a) the queue is empty; or (b) there are inadequate reserves to settle the 
micropayment token at the front of the queue. 

[001 15] Concerning the queue(s) maintained by cPSP module 110, the queue(s) may 
be configured such that (a) all consumers use a common queue, (b) each consimier has their 
own separate queue, or (c) defined groups of consumers share a queue common for that 
defined group. 

[00116] As discussed above, micropayment selection protocol 114 processes 
micropajment tokens in a probabilistic fashion in accordance with a defined percentage or 
ratio. In the example above, this ra.tio is one in one-hxmdred, in that one out of every 
one-himdred micropayment tokens received by the PCS module 104 is selected for 
processing so that cPSP module 110 may bill the consumer for the actual amoimt of the 
purchase and mPSP module 106 may make a macropayment to the merchant via merchant 
banking institution 108. 
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[001 1 7] However, the imselected micropayment tokens still must be processed and the 
consumers billed in order to recover the differential cost between the amoxmt of the 
macropayment made to the merchant and the micropayment token amoimt d collected from 
the consumer. Accordingly, PCS module 104 repeatedly examines the unselected 
micropayment tokens to determine if any of them may be sent to mPSP 106 and cPSP 110 
for processing. 

[00118] Specifically, the PCS module 104 examines 324 each unselected 
micropayment token to make t^vo detemiinations: (a) the actual time period since the 
unselected token was generated; and (b) and the differential amount C/that the coiisimier 
has spent since the last time that the consumer was billed. If 326 the actual time period 
since the micropayment token was generated exceeds a predetermined time period (e.g., 
thirty days), the micropajonent token is digitally signed 320 and transmitted 322 to mPSP 
module 106 for processing. Further, if 328 the differential amomit C/ exceeds a predefined 
minimum billing threshold (e.g., $5.00), the micropayment token is digitally signed 320 
and transmitted 322 to mPSP module 106 for processing. 

[00119] When received 350 by mPSP module 106, the unselected micropayment 
tokens are processed similarly to that of the selected micropayment tokens (i.e., they are 
vaUdated 352 and verified 354). However, since the unselected niicropayment tokens are 
not stepped-up in value to reflect a macropajonent amoimt, no payment is made to the 
merchant concerning these unselected micropayment tokens, as the stepped-up 
macropayments made to the merchant already paid the merchant for any non-selected 
micropayment tokens. 

[00120] Accordingly, when mPSP module 106 receives a non-selected micropayment 
token for processing, the non-selected micropayment token is transmitted 354 to cPSP 
module 1 10 for consumer billing purposes. 

[00121] Each unselected micropayment token specifies the micropajment token 
amount d, and a cumulative spend amount Cy + C/ , such that Cj represents the last amount 



35 



wo 2004/068293 



PCT/US2004/001845 



previously billed to the consumer and C/ represents the differential amount that the 
consumer has spent since the last billing. The cPSP module 110 bills 406 the consumer 
(via the consumer banking institution 112) for the differential amount spent (C/) plus the 
micropayment token amount d. These received funds are then deposited 408 into the queue 
reserve Or, thus raising the value of the queue reserve Or and allowing for the payment of 
additional macropayments to the merchant(s). However, since 418 these are unselected 
micropayment tokens, these unselected tokens are not placed into the queue to await 
macropayment, as macropayments are not made on unselected tokens. 

[00122] Concerning the cumulative spend amount, this value is maintained (on 
storage device 30) by PCS module 104. As stated above, the cCERT retrieved by 
consumer agent module 102 specifies a serial number that allows the consumer agent 
module 102 to retrieve (from PCS module 104) the current cumulative spend amount, 
which is incorporated into any micropayment tokens (e.g., tokens 12, 14, 16) generated by 
the consumer agent module 102. Accordingly, by ensuring the accuracy of the cumulative 
spend amomit maintained on PCS module 104, the accuracy of the cumulative spend 
amomit specified in the micropayment tokens is also ensured. 

[00123] As stated above, the cumulative spend amount is defined as Cy + C/, such that 
Cj represents the last amoimt previously billed to the consumer, and C/ represents the 
differential amount that the consumer has spent since tlie last billing. Accordingly, 
whenever a micropayment token is processed, regardless of whether it is an unselected 
token or a token that was selected by micropayment selection protocol 1 14 as a basis for a 
macropayment, the consumer is billed 406 for the differential amount spent (C/) plus the 
micropayment token amount {d). Therefore, each time a micropajonent token is processed 
(i.e., transmitted to mPSP module 106), the cujiiulatiye spend amount maintained by PCS 
module 104 is updated 314. Wh&n updatmg the cumulative spend amount, Cj is set equal 
to the sum of (Cy), (C/), and {d), and the differential amount spent (C/) is reset to zero (as 
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the client is currently being billed and, therefore, has not purchased anything since their 
last billing). 

[00124] Continuing with the above stated example, when the consumer made their 
seventy-sixth purchase, their micropajTnent token was selected by micropayment selection 
protocol 114. At this point in time, the cumulative spend amount Cj + Cj specified in the 
micropayment token and the PCS module 104 is $7.50, such that Cj (i.e., the last amount 
previously billed to the consumer) is equal to $0.00 (as the consumer has never been billed 
for any of their previous seventy-five purchases) and C/ (i.e., the differential amount that 
the consumer has spent since the last billing) is equal to $7.50, which represents the cost of 
the previous seventy-five unbilled purchases. 

[00125] Accordingly, when updating the cumulative spend amount of this consumer, 
Cj is set equal to the sum of (Cy), (C/), and id), i.e., $0.00 + $7.50 + $0.10. Further, the 
differential amount spent (Q) is reset to zero. Therefore, when the consumer generates a 
seventh-seventh micropayment token, the cumulative spend amount Cy + C/ retrieved fi-om 
the PCS module 104 and incorporated into the seventy-seventh micropayment token will 
be $7.60, such tiiat Cj is equal to $7.60 and C/ is equal to $0.00. 

[00126] Micropayment processing system 10 may access a token processing fee for 
each micropayment token processed. Depending on how the system is configured, one or 
more of the followiug may apply: (a) the consumer may be charged for each token that 
consumer generates; (b) flie merchant may be charged for each token used as a basis for a 
macropayment made to tiiat merchant; or (c) flie merchant may be charged for each token 
directed toward that merchant; for example. 

[00127] Micropayment selection protocol 114, which is fiilly disclosed in and the 
subject of Intemational AppUcation No.: PCT/US02/12189 (attached hereto as Appendix 
A), is a secure selection protocol, in that the module(s) executing the protocol need not be 
operated on a secure system in order for the protocol to be secure. For example, while 
mPSP module 106 and cPSP module 1 10 are typically operated on a secure system, offer 
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development module 100, consimier agent module 102, and. PCS module 104 may be 
operated on non-secure sj^stems, thus lowering the overall operating cost of micropayment 
processing system 10. 

[00128] As described' above, various modules within the micropayment processing 
system 10 hash and digitally sign data objects prior to transmission. Examples include: the 
offer development module 100 that hashes and digitally signs offer packages; the 
consumer agent module 102 that hashes and digitally signs micropayment tokens prior to 
sending them to the PCS module; the PCS module 104 that hashes and digitally signs 
micropayment tokens prior to sending them to the mPSP module; and the mPSP module 
106 that hashes and digitally signs micropayment tokens prior to sending them to the cPSP 
module. 

[00129] Unfortunately, digitally sigmng data objects consumes considerable 
computational bandwidth, especially when compared to the computational bandmdth 
required to hash a data object. As will be discussed below in greater detail, by batch 
processing data objects, large reductions in computational bandwidth can be realized while 
incurring only a modest increase in processing lag time. 

[001 30] Referring also to FIG. 9, batch processing module 450 may be included in any 
of the modules (e.g., modules 100, 102, 104, 106 and/or 110) of the micropayment 
processing system 10. Batch processing module 450 allows for the batch processing of 
data objects (e.g., offer packages and micropayment tokens, for example). 

[00131] As discussed above, each data object is typically hashed and then digitally 
signed. Therefore, for a batch of eight data objects, eight hashing operations and eight 
signing operations would traditionally be required. However, batch processing module 
450 requires only one digital signing operation and 2N-1 hashing operations (i.e., 15 
hashihg operations) per batch of eight data objects processed. Assimiing that it requires 
10"^ times the hash processing power to produce a single digital signature, the traditional 
one-signature-per-object process requires 80,008 processing units (i.e., 8 signatures @ 
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10,000 units each and 8 hashes @ 1 unit each) versus 10,015 processing units (i.e., 1 
signature @ 10,000 units each and 2N-1 hashes @ 1 unit each). Accordingly, the use of 
batch processing module 450 results in a processing bandwidth reduction of 87.48%. 

[00132] The processing bandwidth savings are even more substantial when the batch 
size is increased. For example, for a batch size of sixty-four, the traditional 
one-signature-per-object process requires 640,064 processing units (i.e., 64 signatures @ 
10,000 units each and 64 hashes @ 1 unit each) versus 10,127 processing units (i.e., 1 
signature @ 10,000 units each and 2N-1 hashes @ 1 imit each). Accordingly, for a batch 
size of sixty-four, the use of batch processing module 450 results in a processing 
bandwidth reduction of 98.41%. 

[00133] However, this increased efficiency does not come without cost, as the larger 
the batch size, the longer amount of time required to build such a batch. For example, if 
system 10 is generating one data object per microsecond, a sixtj^-four object batch can be 
assembled in sixty-four microseconds (i.e., most likely an acceptable level of delay). 
However, if system 10 is generating one data object per second, it would take over one 
minute to assemble a sixty-four object batch (i.e., most-likely an imacceptable delay). 

[00134] Accordingly, when defining the batch size, consideration should be given to 
the acceptable level of delay. Therefore, it may be desirable to define a batch as the 
nimiber of objects acquired during a fixed period of time (e.g., 0.100 seconds), such that 
the 0.100 seconds represents the acceptable level of delay. 

[00135] Batch processing module 450 allows a user to define 452 a batch size 
definition. When defining this batch size definition, the user mB.y define 454 the number of 
data objects to be included within the batch. Alternatively, the user may define 456 a time 
period (e.g., 1 00 milliseconds), such that tlie number of data objects included in the batch is 
the number of data objects made available during the time period. 

[00136] Regardless of the maimer in which the batch size is defined (i.e., time period 
or data object number), batch encoding process 450 obtains 458 the data objects required to 
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assemble the batch. If the user defined the batch size as a specific number of data objects, 
batch processing module 450 obtains 460 the specific number of data objects. If the user 
defined the batch size as the number of objects available during a specific time period, 
batch processing module obtains 462 the data objects made available during the specific 
time period. 

[00137] Referring also to FIG. 10, a graphical representation of an encoded batch file 
500 is shown, which represents the end product of batch encoding process 450. hi this 
particular example, batch file 500 includes eight data objects 502-516, each of which may 
represent a micropayment token or an offer package, for example. 

[00138] When generating an encoded batch file (e.g., encoded batch file 500), batch 
encoding process 450 obtains 458 the appropriate nimiber of data objects (e.g., data objects 
502-516). Once these data objects are obtained, batch processing module 450 hashes 464 
each data object to generate a hashed data object for each data object. 

[00139] Once hashed 464, these hashed data objects are grouped 466 into pairs of 
hashed data objects (e.g., object pair 502/504, object pair 506/508, object pair 510/512, and 
object pair 514/516) and these pairs of hashed data objects are hashed 468, thus producing 
four hashed data objects 518, 520, 522, 524 (respectively), each of which corresponds to a 
single pair of hashed data objects. Batch encoding process 450 monitors 470 fee number of 
hashed data objects generated when hashing 468 fee pairs of hashed data objects, and this 
grouping 466 and hashing 468 is recursively repeated until there is only one hashed data 
object generated. 

[00140] Continuing wife the above-stated example, as four hashed data objects were 
generated, feese four hashed data objects are grouped 466 into two pairs of hashed data 
objects (e.g., object pair 518/520, and object pair 522/524) and these two pairs of hashed 
data - objects are hashed 468, feus producing tv/o hashed data objects 526, 528 
(respectively). 
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[00141] Since batch processing module 450 detertnines 470 that more than one 
hashed data object was generated, these two hashed data objects are grouped 466 into one 
pair of hashed data objects (e.g., object pair 526/528) and this pair of hashed data objects is 
hashed 468, thus producing one hashed data object 530. 

[001 42] Since batch processing module 450 determines 470 that only one hashed data 
object was generated, batch processing module 450 digitally signs (i.e., encrypts) 472 the 
hashed data object, and the digitally signed, hashed data object is transmitted 474 to the 
intended recipient. As will be explained below in greater detail, once this digitally signed, 
hashed data object is received by the intended recipient, any of the original eight data 
objects 502-516 maybe decoded. 

[00143] In the above-stated example, the grouping 466 of the eight hashed data 
objects resulted m four pairs, which were hashed 468 and resulted in two pairs, which were 
hashed 468 and resulted in one pair, which was hashed 468, signed 472, and transmitted 
474. Unfortunately, this grouping and hashing only works this smoothly when the initial 
number of data objects is a power of two (i.e., 2, 4, 8, 16, 32, 64, or 128, for example). 
However, if the user of batch processing module 450 defines 452 a batch size by defining 
456 a time period, the number of data objects processed may be any number. 

[00144] According, when processing hashed data objects, if the number of hashed 
data objects being paired is an odd number, tliose data objects that could be paired are 
paired and the single, non-pairable hashed data object is subsequently paired at a higher 
level. This subsequent pairing occurs when hashing process 468 generates an odd number 
of hashed data objects. 

[00145] For example, assume that in addition to the eight data objects (i.e., data 
objects 502-516) processed in the above-stated example, a ninth data object 532 is also 
processed. The pairing of this ninth data 532 is delayed until an odd number of hashed data 
objects is generated. As stated above, the pairing of the eight data objects results in four 
pairs (i.e., object pair 502/504, object pair 506/508, object pair 510/512, object pair 
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514/516); which are hashed and grouped, resulting in two pairs (i.e., object pair 518/520, 
object pair 522/524); which are hashed and grouped, resulting in a single pair (i.e., object 
pair 526/528); which is hashed and results in a single hashed data object 530. As hashed 
data object 530 represents the first time that a single hashed data object is generated, the 
ninth data object 532 is hashed 464 and paired 466 with hashed data object 530, resulting in 
object pair 530/532. Object pair 530/532 is subsequently hashed 468, and new hashed data 
object 534 is generated. 

[00146] Referring also .to FIG. 11, verification module 550 maybe included in any of 
the modules (e.g., modules 100, 102, 104, 106 and/or 110) of the micropayment processing 
system 10. Verification module 550 allows for the verification of the digitally signed, 
hashed data objects (e.g., data object 530) generated by batch processing module 450. 

[00147] Verification module 550 receives 552 the digitally signed, hashed, data 
object 530, which (as discussed above) is a multi-level data object that represent multiple 

levels of data witliin an encoded batch file 500. Data object 530 includes a hashed target 

\ ■ 

data object (e.g., data object502) and one or more hashed, non-target data objects (i.e., data 
objects 504-528). 

[00148] Verification module 550 also receives 554 one or more sequential data keys 
(e.g., data objects 504, 520, 528), such that each of these sequential data keys corresponds 
to a hashed non-target data object at a unique level within the digitally-signed, hashed data 
object 530. Additionally, verification module 550 receives 556 a non-hashed target data 
object 536 (e.g., a non-hashed version of hashed target object 502). 

[00149] Through the use of the data keys (e.g., data objects 504, 520, 528) and the 
non-hashed target data object 536, the validity of signed, hashed, data object 530 and target 
data object 502 (embedded within signed, hashed, data object 530) can be confirmed. 

[00150] Continuing with the above-stated example, assume that hashed, multi-level 
data object 530 was digitally signed by batch processing module 450 and is received 552 
by verification module 550. As discussed above, data object 530 is an hashed data object 
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that includes the information from eight data objects, namely data objects 502-516. 
Assume that data object 502 is tlie hashed target data object (i.e., the offer package or token 
to be processed). Being the patli between data object 530 and data object 502 sphts three 
times, three data keys are required to map the path between these two data objects and, 
therefore, vaUdate the integrity of the hashed' target data object (i.e., data object 502) 
specifically and the hashed data object 530 generally. 

[00151] Specifically, these three data keys correspond to the hashed values of the data 
objects on the non-selected paths of a data split. For example, when mapping from data 
object 530 to the target data object 502, the first split encountered is the split between data 
object 526 and data object 528. As data object 526 is the selected path (i.e., data object 526 
maps toward data object 502), data object 528 Ues on the non selected path and, therefore, 
the hashed value of data object 528 is one of the three data keys required to validate data 
object 502. The other twp data keys are data object 520 (i.e.,.for the second spUt) and data 
object 504 (i.e., for the third split). 

[00152] Therefore, continuing with the above-stated example, verification module 
550 receives 554 the three data keys required to validate target data object 502. As 
explained above, these data keys are hashed data objects 528, 520, and 504. Additionally, 
verification module 550 receives 556 the non-hashed, target data object 536. 

[00153] Verification module 550 hashes 558 non-hashed, target data object 536 to 
generate a first level hashed data object (i.e., data object 502 within multi-level, data object 
530). Module 550 groups 560 hashed data object 502 (i.e., the first level hashed data object) 
with the first level sequential data key (i.e., data object 504) to generate first level 
object/key pair 502/504, which is hashed 562 to generate a second level hashed data object 
(i.e., hashed data object 518). If 564 all of the sequential data keys were not paired with 
hashed data objects, the grouping process 560 and the hashing process 562 must be 
repeated until all sequential data keys are exhausted. 
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[00154] As there are two sequential data keys remaining (i.e., data keys 520, 528), 
verification module 550 groups 560 second level hashed data object 518 with the second 
level sequential data key (i.e., data object 520) to generate second level object^ey pair 
518/520, which is hashed 562 to generate a third level hashed data object (i.e., hashed data 
object 526). 

[001 55] As there is one sequential data key remaining (i.e., data key 528), verification 
module 550 groups 560 tliird level hashed data object 526 with the third level sequential 
data key (i.e., data object 528) to generate third level object/key pair 526/528, which is 
hashed 562 to generate a fourth level hashed data object (i.e., hashed data object 530). 

[00156] As there are no sequential data keys remaining, the grouping process 560 and 
the hashing process 562 are complete. Optionally, module 550 decrypts 566 hashed, 
multi-level data object 530 to generate a decrypted, hashed multi-level data object (i.e., a 
decrypted version of hashed, multi-level data object 530). Module 550 then compares 568 
this decrypted version of hashed, multi-level data object 530 to the fourth level hashed data 
object to see if they match. In the event that these two data objects match, the vahdity of 
the multi-level data object 530 and target data object 502 are confirmed. 

[00157] While hashed data objects are described above as being grouped into pairs of 
hashed data objects, other configurations are possible in which larger numbers of hashed 
data objects are grouped together. 

[00158] While the content receipt that is transmitted to the consumer agent module is 
described above as typically including a decryption key that allows the consxmier to access 
the products/services purchased, other more complex configurations that utilizes a series of 
keys are possible. 

[00 159] For example, PCS module 1 04 may generate a PCS MCK encrs'ption key pair, 
and the pubhc key portion may be stored v/ithin the mCERT. The offer development 
module 100 may produce a sj'mmetric master content key on a periodic process. The offer 
development module 100 would store the master content key, as well as a copy of the 
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master content key encrypted by the public key of the PCS MCK encryption key pair. This 
master content key set (i.e., the encrypted and non-encrypted versions) may be used for any 
' munber of offer packages, as described below. 

[00160] For example, for each offer .package, the offer development module lOQ.may 
generate a symmetric content key, such that the content key is used to encrypt the offer 
package content file (e.g., the song, or URL, for example). The offer development module 
100 then uses the master content key to encrypt the content key, such that the encrypted 
content key and the encrypted master content key are stored inside the offer package. The 
offer development module 100 then signs the entire offer package using the encryption key 
within the mCERT. 

[00161] Once the PCS module 104 validates the micropayment token, the PCS 
module 104 decrypts the content key for the given micropa^anent token as follows. If the 
master content key for this micropayment token is not cached, decrypt the master content 
key using the PCS MCK encryption key and cache the master content key for future use. 
Otherwise, use the cached master content key to decr^'pt the content key using the 
decrypted, cached master content key. The resulting content key is then sent to the 
consumer agent module 102 with the content receipt. 

[00162] While the micropayment processing system is shown to service only one 
merchant (i.e., merchant IS), other configurations are possible. For example, the 
micropayment processing system may be configured to process micropayment tokens 
directed to multiple merchants, such as merchants 46, 48. Additionally, the micropayment 
processing system may include multiple PCS modules configured to process 
micropaj'ment tokens directed to a single larger merchant. Further, as the micropayment 
processing system is scalable, banks of PCS modules may be configured to distributedly 
process micropayment tokens directed to multiple merchants. 

[00163] While modules 100, 102, 104, 106, and 110 are described above as being 
directly accessed, other configurations are possible that allow for access via proxies. For 
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example, offer development module 100 may be accessed via a browser appUcation (e.g., 
Microsoft Intemet Explorer or Netscape Navigator that is rumiing on merchant 
computer 50. Accordingly, the browser application would allow for the merchant to access 
ofifer development module 100 (which is operating remotely on a web server) and remotely 
configure offer packages that are reviewable by the consiraier. 

[00 1 64] While a monetary cost is associated with each offer package described above, 
other configurations are possible. For example, the cost of an offer package may be 
specified in firequent flyer miles, in that a consumer uses their fi-equent flyer miles., to 
purchase products/services. Alternatively, the cost of an ofifer package may be specified in 
consumer points, such that consumers earn points each time they purchase consumer 
products (e.g., soda, cereal, or potato chips, for example), and the points earned may be 
used to purchase products/services, for example. 

[00 1 65] While the above-described system discloses verifying age requirements at the 
time tliat a micropayment token is received for processing by the PCS module, other 
configurations- are possible. For example, tlie system may be configured so that the 
consumer agent module only allows a consumer to review the details of an ofifer package if 
that consumer meets the age requirements. 

[00166] While the above-described system discloses verifying account balances at the 
time that a micropayment token is generated by the consumer agent module, other 
configurations are possible. For example, the system may be configured so that the 
consumer agent module only allows a consumer to review the details of an offer package if 
that consimier has a sufficientiy high account balance. 

[00167] While micropayment selection protocol is described above as selecting a 
defined percentage of micropayment tokens for processing and increasing the value of the 
selected micropayment tokens by the inverse of this defined percentage, other 
configurations are possible, such as the merchant defining the desired size of the 
macropayment. For example, if a merchant wanted to receive macropayments of $100.00 
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and the value d of the micropayment tokens are $0.20 each, the scaling factor would be 
^^^^'^^/%020 (i.e., 500) and, therefore, the selection ratio would be set so that one out of every 
five-hundred tokens is selected for processing. 

[00 1 68] While the micropayment system is described above as locally storing the data 
files offered for purchase by the merchant(s) using the system, other configurations are 
possible. For example, a third-party data rights management system 116 may be utilized 
tliat allows for the remote storage of data files. Additionally, data rights management 
system 116 may also control the access and downloading of the data files, 

[00169] While the consxxmer is shown as accessing micropayment processing system 
exclusively through the use of a computer, other configurations are possible. For example, 
the consumer may access the micropayment system via a handheld device, such as a 
cellular telephone, or a personal digital assistant (e.g. a Pahn ^ or Pocket PC ^"^ handheld 
device, not shown), 

[00170] A number of implementations have been described. Nevertheless, it will be 
understood that various modifications may be made. Accordingly, other implementations 
are within the scope of the following claimis. 
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WHAT IS CLAIMED IS: 

1 . A method of producing an offer package comprising: 

defining, within the offer package, a description of an offered product; 
defining, within the offer package, a cost of the offered product; 
defining, within the offer package, a merchant that is making the offer; and 
including, within the offer package, an encrypted version of the offered 
product. 

2. The method of claim 1 further comprising: 

defining, within the offer package, a use duration for the offered product. 

3. The method of claim 1 fiurther comprising: 

defining, within the offer package, the currency of the offer. 

4. The method of claim 1 fiirfher comprising: 

defining, within flie offer package, an expiration date of the offer. 

5. The method of claim 1 fiirther comprising: 

digitally signing the offer package. 



6. The method of claim 1 fiuther comprising: 

encrypting the offered product to generate the encrypted-version of the 
offered product. 
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7. A method of producing an offer package comprising: 

defining, within the offer package, a description of an offered 
^ ' product/service; 

defining, within the offer package, a cost of the offered product/service; 
defining, within the offer package, a merchant that is making the offer; and 
including, witliin the offer package, an encrypted link to the offered 
product/service. 



8. The method of claun 7 further comprising: 

defining, within the offer package, a use duration for the offered 
product/ser\dce. 



9. The method of claim 7 fiirther comprising: 

defining, within the offer package, the currency of the offer. 

10. The method of claim 7 finlher comprising: 

defining, within the offer package, an expiration date of the offer. 

1 1 . The method of claim 7 fiirther comprising: 

digitally signing the offer package. 



12. The method of claim 7 fiirther comprising: 

encrj'pting a link to tlie offered product/service to generate the encrj'pted 

link. 
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13. A method of reducing download fraud comprising: 

defining an offer package, wherein the offer package includes a offer 
description and:,an encrypted version of the offered product; and 

requiring that a potential consumer download the offer package prior to 
being able to review the offer description. 

14. The method of claim 13 further comprising: 

requiring that a potential consumer download the offer package prior to 
being able to purchase the offer package. 



15. The method of claim 14 further comprising: 

allowing the potential consumer to decrypt the encrypted version of the 
offered product in response to the potential consumer purchasing the offer package. 

16. The method of claim 15 wherein allowing the potential consimier to decrypt 
includes: 

providing the potential consumer with a decryption key that allows the 
potential consumer to decrypt the encrypted version of the offered product. 



4 
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17. A method of processing an ofifer package comprising: 
validating the ofifer package; 
accepting the offer package; 

determining a cumulative spend amount for the consirmer that accepted the 
offer package; and 

generating a micropayment token that identifies the offer package and the 
cumulative spend amoxmt. 



18. The method of claim 17 further comprising: 

reviewing an offer description included within the offer package prior to 
accepting the offer package. 



19. The metliod of claim 17 further comprising: 

digitally signing the micropa3'ment token. 

20. The method of claim 17 further comprising: 

transmitting the micropayment token to a token processing system. 

2 1 . The method of claim 20 further comprising: 

receiving a decryption key from the token processing system. 



22. The method of claim 2 1 wherein: 

the offer package concerns an offered product; 

the offer package includes an encrypted version of the offered product; and 
the decryption key allows the consumer to decrypt the encrypted version of 
the offered product. 
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23 . The method of claim 2 1 wherein: 

the offer package concerns an offered product/service; 

the offer package includes an encrypted link to the offered product/service; 

and>. 

the decryption key allows the consumer to decrypt the encrypted link. 

24. The method of claim 17 wherein determining a cumulative spend amount includes: 

obtaining a consumer certificate, concerning the consumer that accepted the 
offer package, from a token processing system; 

wherein the consumer certificate includes a consumer identifier that allows 
for the retrieval of the cumulative spend amount. 

25 . The method of claim 1 7 fiirther comprising: 

retrieving the offer package fi-om a remote location. 
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26. A method of processing micropayment tokens comprising: 

receiving a micropayment token from a remote source, wherein the 
micropayment token concerns an offer package that was offered by a merchant and 
accepted by a consumer; 

validating the micropayment token; 

accepting the micropayment token for processing; and 

selecting micropayment tokens for macropayment processing. 

27. The method of claim 26 further comprising: 

transmitting a decryption key to the consumer. 

28. The method of claim 26 wherein validating the micropayment token includes: 

validatmg the offer package that was offered by the merchant and accepted 
by the consumer. 

29. The method of claim 26 wherein validating the micropayment token includes: 

verifying that the offer package has not expired. 



30. The method of claim 26 wherein selecting micropayment tokens for macropayment 
processing includes: 

defining the accepted micropajonent tokens as either selected 
micropayment tokens or unselected micropajonent tokens; 

wherein the selected micropayment tokens are used as the basis for pajdng a 
macropayment amount to the merchant. 

31. The method of claim 30 wherein defining the accepted micropayment tokens 
includes: 
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defining the accepted micropayment tokens in accordance with a defined 
selection percentage. 

32. The method of claim 3 1 wherein the defined selection percentage fs one percent, 
resulting in one selected micropayment token for each ninety-nine unselected 
micropayment tokens. 

33. The method of claim 31 wherein the defined selection percentage is ten percent, 
resulting in one selected micropayment token for each nine unselected micropayment 
tokens. 

34. The method of claim 31 wherein each selected micropayment token defines a 
micropayment token amount, the method fiirther comprising: 

increasing the micropayment token amoimt in accordance with the raverse 
of the defined selection percentage, thus definiag the macropayment amomit. 

35. The method of claim 34 further comprising: 

digitally signing the micropayment token. 

36. The method of claim 30 wherein defining the accepted micropayment tokens 
includes: 

defining the accepted micropayment tokens in accordance with a desired 
macropayment amount. 

37. The method of claim 36 wherein the desired macropayment amount is $100. 
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38. A method of processing selected micropayment tokens comprising: 

validating a selected micropayment token; and 
queuing^the selected micropayment token; 

wherein the selected micropayment token defines a macropayment amount, 
defines a micropayment token amoimtj and concerns an offer package that was 
offered by a merchant and accepted by a consumer. 

39. The method of claim 38 wherein validating the selected micropayment token 
includes: 

validating the offer package that was offered by the merchant and accepted 
by tlae consumer. 

40. The method of claim 38 wherein validating the selected micropayment token 
includes: 

verifying that the offer package has not expired. 

41. The method of claim 38 wherein queuing the selected micropa>Tnent token 
includes: 

placing the selected ntiicropayment token into a processing queue, wherein a 
queue reserve is associated with the processing queue. 

42. The method of claim 41 wherein the processing queue is a FIFO queue. 

43. The method of claim 41 wherein each selected micropayment token further defines 
a cumulative spend amount, which is the sum of: 

a last amount previously billed to the consumer; and 

a differential amount that the consumer has spent since the last billing. 
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44. The method of claim 43 further comprising: 

hi llin g a consmner banking institution that is associated with the consumer 
for the sum of the micropayment token amount and the differential amount. 

45. The method of claim 44 further comprising: 

setting the last amount previously billed to the consumer equal to the sum 

of: 

die last amount previously billed to the consxmier; 
the differential amount; and 
the micropayment token amount. 

46. The method of claim 45 further comprising: 

setting the differential amount equal to zero, 

47. The method of claim 43 further comprising: 

depositing the sum of the micropayment token amount and the differential 
amount into the queue reserve associated with the processing queue. 

48. The method of claim 41 further comprising: 

comparing the macropayment amount of a next-to-be-processed selected 
micropayment token within the processing queue to the value of the queue reserve. 

49. The method of claim 48 wherein the next-to-be-processed selected micropayment 
tokeii is the selected micropajonent token in a front position of the processing queue. 

50. The method of claim 48 further comprising: 
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depositing the macropayment amount dej5ned in the next-to-be-processed 
selected micropayment token into a merchant banking institution associated with 
the merchant. 

V 
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51. A method of processing iinselected micropayment tokens comprising: 

authorizing for processing an imselected micropayment token; and 
vahdating the unselected micropayment token; 

wherein the uflselected micropayment token defines a micropayment token 
amount, a cumulative spend amount, and concerns an offer package that was 
offered by a merchant and accepted by a consumer; 

wherein the cumulative spend amount is the sum of: 

a last amoimt previously billed to the consumer; and 

a differential amount that the consumer has spent since the last 

bilUng. 

52. The method of claim 51 wherein validating the unselected micropayment token 
includes: 

validating the offer package that was offered by the merchant and accepted 
by the consumer. 

53. The method of claim 51 wherein validating the unselected micropayment token 
includes: 

verifying that the offer package has not expired. 

54. The method of claim 51 further comprising: 

placing the unselected micropajonent token into a processing queue, 
v/herein a queue resen^e is associated with the processing queue. 

55. The method of claim 54 wherein the processing queue is a FIFO queue. 

56. The method of claim 54 further comprising: 
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billing a consumer banking institution that is associated with the consumer 
for the sum of the micropayment token amount and the differential amount. 

57. The method of claim 56 further comprising: 

setting the last amount previously billed to the consumer equal to the sum 

of; 

the last amount previously billed to the consumer; 
the differential amount; and 
the micropayment token amount. 

58. The method of claim 57 further comprising: 

setting the differential amount equal to zero. 

59. The method of claim 54 further comprising: 

depositing the sum of the micropayment token amount and the differential 
amount into the queue reserve associated with the processing queue. 



60. The method of claim 51 wherein authorizing for processing an unselected 
micropayment token includes: 

comparing a predetermined time period to an actual time period since the 
unselected micropayment token was generated; 

wherein the unselected micropayment token is authorized for processing if 
the actual time period exceeds the predetermined time period. 

61 . The method of claim 60 wherein the predetermined time period is thirty days. 

62. The method of claim 51 wherein authorizing for processing an unselected 
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micropayment token includes: 

comparing a predefined minimum billing threshold to the differential 
amount; 

wherein the unsel-ected micropayment token is authorized for processing if 
the differential amount exceeds the predeteraiined time period. 

63. The method of claim 62 wherein the predefined minimum billing threshold is five 
dollars. 
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.64. A computer program product residing on a computer readable medium having a 
plurality of instmctions stored thereon which, when executed by the processor, cause that 
-processor to: 

define, within an offer package, a description of an offered product; 
define, within the offer package, a cost of the offered product; 
define, within the offer package, a merchant that is making the offer; and 
include, within the offer package, an encrypted version of the offered 
product. 

65. The computer program product of claim 64 fiirther comprising instructions for: 

defining, within the offer package, a use duration for the offered product. 

66. The computer program product of claim 64 fiirther comprising instmctions for: 

defining, within the offer package, the currency of the offer, 

67. The computer program product of claim 64 fiirther comprising instmctions for: 

defining, within the offer package, an expiration date of the offer. 

68. The computer program product of claim 64 fiirflier comprising instmctions for: 

digitally signing the offer package. 

69. The computer program product of claim 64 fiirther comprising instmctions for: 

encrypting the offered product to generate the encrs'pted-version of the 
offered product. 
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70. A computer program product residing on a computer readable medium ha\dng a 
plurality of instructions stored thereon which, when executed by the processor, cause that 
processor to: 

dejSne, within an offer package, a description of an offered product/service; 
define, within the offer package, a cost of the offered product/service; 
define, within the offer package, a merchant that is making the offer; and 
include, within the offer package, an encrypted link to the offered 
product/service. 

71. The computer program product of claim 70 fiirther comprising instructions for: 

defining, within the offer package, a use duration for the offered 
product/ser\dce. 

72. The computer program product of claim 70 further comprising instructions for: 

defining, within the offer package, the currency of the offer. 

73. The computer program product of claim 70 further comprising instructions for: 

defining, within the offer package, an expiration date of the offer. 

74. The computer program product of claim 70 further comprising instructions for: 

digitally signing the offer package. 

75. The computer program product of claim 70 further comprising instructions for: 

encrypting a link to the offered product/sen/ice to generate tlie encrj^pted 

^ link. 
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76. A computer program product residing on a computer readable medium having a 
plurality of instructions stored thereon which, when executed by the processor, cause that 
processor to: 

define an offer package, wherein the offer package includes a offer 
description and an encrypted version of the offered product; and 

require that a potential consumer download the offer package prior to being 
able to review the offer description. 

77. The computer program product of claim 76 further comprising instructions for: 

requiring that a potential consumer download the offer package prior to 
being able to purchase the offer package. 

78. The computer program product of claim 77 further comprising instmctions for: 

alloAving the potential consumer to decrypt the encrypted version of the 
offered product in response to the potential consumer purchasing the offer package. 

79. The computer program product of claim 78 wherein the instructions for allowing 
the potential consumer to decrypt include instructions for: 

providing the potential consimier with a decryption key that allows the 
potential consumer to decrypt the encrypted version of the offered product. 
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80. A computer program product residing on a computer readable medium having a 
plurality of iastructions stored thereon which, when executed by the processor, cause that 
processor to: 

validate an offer package; '"^ 
accept the offer package; 

detemiine a cumulative spend amount for ttie consxmier that accepted the 
offer package; and 

generate a niicropayment token that identifies the offer package and the 
cumulative spend amount. 

81. The computer program product of claim 80 further comprising instructions for: 

reviewing an offer description included witliin the offer package prior to 
accepting the offer package, 

82. The computer program product of claim 80 further comprising instructions for: 

digitally signing the micropayment token. 

83 . The computer program product of claim 80 further comprising instructions for: 

transmitting the micropayment token to a token processing system. 

84. The computer program product of claim 83 further comprising instructions for: 

receiving a decryption key from the token processiug system. 

85. The computer program product of claun 84 wherein: 

the offer package concems an offered product; 

the offer package includes an encrypted version of the offered product; and 
the decryption key allows the consumer to decrypt the encrypted version of 
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the offered product. 

86. The computer program product of claim 84 wherein: 

the offer package concerns an offered product/service; 

the offer package includes, an encrypted hnk to the offered product/service; 

and 

the decryption key allows tlie consumer to decrypt the encrypted link. 

87. The computer program product of claim 80 wherein the instructions for 
determining a cumulative spend amount include instructions for: 

obtaining a consumer certificate, concerning the consumer that accepted the 
offer package, from a token processing system; 

wherein the consumer certificate includes a consumer identifier that allows 
for the retrieval of the cxmiulative spend amount. 

88. The computer program product of claim 80 fiirther comprising instractions for: 

retrieving the offer package from a remote location. 
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89. A computer program product residing on a computer readable mediimi having a 
plurality of instructions stored thereon which, when executed by the processor, cause that 
processor to: 

receive a micropayment token ,from a remote source, wherein the 
micropayment token concerns an offer package that was offered by a merchant and 
accepted by a consumer; 

vahdate the micropayment token; 

accept the micropayment token for processing; and 

select micropayment tokens for macropayment processing. 

90. The computer program product of claim 89 further comprising instmctions for: 

transmitting a decr3'ption key to the consimier. 

91 . The computer program product of claim 89 wherein the instmctions for validating 
the micropayment token include instmctions for: 

validating the offer package that was offered by the merchant and accepted 
by the consumer. 

92. The computer program product of claim 89 wherein the instmctions for validating 
the micropayment token include instmctions for: 

verifying that the offer package has not expired. 

93. Tlie computer program product of claim 89 wherein the instmctions for selecting 
micropayment tokens for macropajoiient processing include instiTictions for: 

defining the accepted micropayment tokens as either selected 
micropayment tokens or unselected micropayment tokens; 

wherein the selected micropayment tokens are used as the basis for paying a 
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macropayment amount to the merchant. 

94. The computer program product of claim 93 wherein the instructions for defining 
the accepted micropayment tokens include instructions for: 

defining the accepted micropayment tokens in accordance with a defined 
selection percentage. 

95. The computer program product of claim 94 wherein the defined selection 
percentage is one percent, resulting in one selected micropayment token for each 
ninety-nine unselected micropayment tokens. 

96. The computer program product of claim 94 wherein the defined selection 
percentage is ten percent, resulting in one selected micropayment token for each nine 
tmselected micropayment tokens. 

97. The computer program product of claim 94 wherein each selected micropayment 
token defines a micropayment token amount, the computer program product fiirther 
comprising instructions for: 

increasing the micropayment token amount in accordance with the inverse 
of the defined selection percentage, thus defining the macropayment amoimt. 

98 The computer program product of claim 97 fiirther comprising instmctions for: 
digitally signing the micropayment token. 

99. The computer program product of claim 93 wherein the instructions for defining 
the accepted micropayment tokens include instmctions for: 

defining the accepted micropayment tokens in accordance with a desired 
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macropayment amount. 

100. The computer program product of claim 99 wherein the desired macropayment 
amount is $100. 
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101. A computer program product residing on a computer readable medium having a 
plurality of instructions stored thereon which, when executed by the processor, cause that 
processor to: 

vahdate a selected micropayment token; and 
queue the selected micropayment token; 

wherein the selected micropayment token defines a macropa^ent amount, 
defines a micropayment token amount, and concems an offer package that was 
offered by a merchant and accepted by a consumer. 

1 02. The computer program product of claim 101 wherein the instmctions for vahdatmg 
the selected micropayment token include instmctions for: 

validating the offer package that was offered by the merchant and accepted 
by the consumer. 

103. The computer program product of claim 101 wherein the iastractions for validating 
the selected micropayment token include instructions for: 

verifying that the offer package has not expired. 

104. The computer program product of claim 101 wherein the instmctions for queuing 
the selected micropayment token include instmctions fon 

placing the selected micropaj/ment token into a processing queue, whereia a 
queue reserve is associated with the processing queue. 

105. The computer program product of claim 104 wherein the processing queue is a 
FIFO queue. 

106. The computer program product of claim 104 wherein each selected micropayment 



69 



wo 2004/068293 



PCT/US2004/001845 



token further defines a cumulative spend amount, which is the sum of: 
a last amount previously billed to the consimier; and 
" " a differential amount that the consumer has spent since the last billing. 

107. The computer program product of claim 106 further comprising instmctions for: 

billing a consumer banking institution that is associated with the consimier 
for the sum of the micropayment token amount and the differential amount. 

1 08. The computer program product of claim 1 07 further comprising instractions for: 

setting the last amount previously billed to the consumer equal to the sum 

of: 

the last amount previously billed to tlie consumer; 
the differential amount; and 
micropayment token amount. 

109. The computer program product of claim 108 further comprising instmctions for: 

setting the differential amount equal to zero. 

110. The computer program product of claim 106 further comprising instractions for: 

depositing the smn of the^micropayment token amount and the differential 
amoirnt into the queue reserve associated with the processing queue. 

111. The computer program product of claim 1 04 further comprising instractions for: 

comparing the macropayment amount of a next-to-be-processed selected 
micropajonent token v/ithin the processing queue to the value of the queue reserve. 

112. The computer program product of claim 111 wherein the next-to-be-processed 
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selected micropayment token is the selected micropayment token in a front position of the 
processing queue. 

113. The computer program product of claim 111 further comprising instructions for: 

depositing the macropayment amount defined in the next-to-be-processed^ 
selected micropayment token into a merchant banking institution associated with 
the merchant. 
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114. A computer program product residing on a computer readable- medium having a 
plurality of instractions stored thereon which, when executed by the processor, cause that 
processor to: 

authorize for processing an unselected micropayment token; and 
vaKdate the unselected micropayment token; 

wherein the unselected micropayment token defines a micropayment token 
amount, a cumulative spend amount, and concems an offer package that was 
offered by a merchant and accepted by a consumer; 

wherein the cmnulative spend amoxmt is the sum of: 

a last amount previously billed to the consumer; and 

a differential amount that the consumer has spent since the last 

bilhng. 

115. The computer program product of claim 114 wherein the instructions for validating 
the unselected micropayment token include instmctions for: 

vaUdatmg the offer package that was offered by the merchant and accepted 
by the consumer. 

116. The computer program product of claim 1 14 wherein the instructions for vaUdating 
the unselected micropayment token include instructions for: 

verifjdng that the offer package has not expired, 

117. The computer program product of claim 114 furtlier comprising instructions for: 

placing the unselected micropayment token into a processing queue, 
wherein a queue resen'^e is associated with the processing queue. 



118. The computer program product of claim 117 wherein the processing queue 



is a 
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FIFO queue. 

■ 119. The computer program product of claim 117 further comprising instmctions for: 

billing a consumer banking institution that is associated with the consumer 
for the sum of the micropayment token amount and the differential amount. 

120. The computer program product of claim 119 further comprising instmctions for: 

setting the last amount previously billed to the consumer equal to the sum 

of: 

tlie last amoxmt previously billed to the consumer; 
the differential amount; and 
the micropayment token amount. 

121 . The computer program product of claim 120 further comprising instmctions for: 

setting the differential amoimt equal to zero. 

122. The computer program product of claim 117 further comprising instmctions for: 

depositing the sum of the micropayment token amount and the differential 
amount into the queue reserve associated with the processing queue. 

123. The computer program product of claim 114 wherein the instmctions for 
authorizing for processing an unselected micropayment token include instmctions for: 

comparing a predetermined time period to an actual time period since the 
unselected micropayment token was generated; 

wherein the unselected micropajonent token is authorized for processing if 
the actual time period exceeds the predetermined time period. 
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124. The computer program product of claim 123 whereiu the predetermined time 
period is thirty days. 

125. The computer program product of claim 114 wherein the instructions for 
authorizing for processing an unselected micropayment token include instructions for: 

comparing a predefined minimum billing threshold to the differential 
amount; 

wherein tlie unselected micropayment token is authorized for processing if 
the differential amount exceeds the predetermined time period. 

126. The computer program product of claim 125 wherein the predefined minimum 
billing tlireshold is five dollars. 
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127. A batch encoding method comprising: 
defining a batch size definition; 

obtaining two or more data objects that satisfy the batch size definition; 
• hashing each data object to generate an N^^ order hashed data object for each 
data object; 

grouping the N**' order hashed data objects into one or more pairs of 
order hashed data objects; and 

hashing each pair of N^^ order hashed data objects to generate an N^"*"^ order 
hashed data object for each pair of N"' order hashed data objects; 

wherein grouping the order hashed data objects and hashing each pair of 
N^^ order hashed data objects is recursively repeated until there is only one N**^^ 
order hashed data object generated. 



128. The method of claim 127 fiaither comprising: 

digitally signing tlie N'^^ order hashed data object. 

129. The method of claim 127 wherein: 

the number of order hashed data objects generated is an odd number; 

and 

grouping the N* order hashed data objects results in one or more pairs of 
N^^ order hashed data objects and a siagle order hashed data object. 



130. The method of claim 129 wherein: 

grouping the N* order hashed data objects includes grouping the siagle N* 
order hashed data object with an M* order hashed data object, wherein the M' 
order hashed data object is a higher order hashed data object than the single 
order hashed data object; and 
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hashing each pair of N order hashed data objects includes hashing the 
single N*^ order hashed data object with the order hashed data object to generate 
an M^^"^^ order hashed data object. 

131. The method of claim 127 wherein defining a batch size definition includes: 

defining a time period. 

132. The method of claim 131 wherein the time period is 100 milliseconds. 



133. The method of claim 131 wherein obtaining two or more data objects includes: 

obtaining data objects made available during the time period. 

134. The method of claim 127 wherein defining a batch size definition includes: 

defining a number of data objects. 

135. The method of claim 127 wherein the data object is a micropayment token. 

136. The method of claun 135 wherein the micropayment token is a selected 
micropayment token. 

137. The method of claim 135 wherein the micropayment token is an unselected 
micropayment token. 

138. The method of claim 127 wherein the data object is an offer package. 
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139. A computer program product residing on a computer readable medium having a 
plurality of instructions stored thereon which, when executed by the processor, cause that 
processor to: ** 

define a batch size definition; 

obtain two or more data objects that satisfy the batch size definition; 
hash each data object to generate an N*^ order hashed data object for each 
data object; 

group the N^^ order hashed data objects into one or more pairs of N^*^ order 
hashed data objects; and 

hash each pair of order hashed data objects to generate an N^^**"^ order 
hashed data object for each pair of order hashed data objects; 

wherein grouping the N^^^ order hashed data objects and hashing each pair of 
N*^ order hashed data objects is recursively repeated until there is only one N*^"^^ 
order hashed data object generated. 

140. The computer program product of claim 139 fiirther comprising instructions for: 

digitally signing the N*"^^ order hashed data object. 

141 . The computer program product of claim 139 wherein: 

the number of order hashed data objects generated is an odd number; 

and 

grouping the order hashed data objects results in one or more pairs of 
N^^ order hashed data objects and a single M* order hashed data object. 

142. The computer program product of claim 141 wherein: 

the instructions for grouping the N^^ order hashed data objects include 
instructions for grouping the single N**' order hashed data object with an order 
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hashed data object, wherein the M order hashed data object is a higher order 
hashed data object than the single N^^ order hashed data object; and 

the instiiictions for hashing each pair of N^^ order hashed data objects 
include instructions for hashing the single order hashed data object with the M*- 
order hashed data object to generate an M'^"^^ order hashed data object. 

1 43 . The computer program product of claim 1 3 9 wherein the instructions for defining a 
batch size definition include instructions for: 

defining a time period. 

144. The computer program product of claim 143 wherem the time period is 100 
milliseconds. 

145. The computer program product of claim 143 wherein the instructions for obtaining 
two or more data objects include instmctions for: 

obtaining data objects made available during the time period. 

146. The computer program product of claim 139 wherein the instructions for defining a 
batch size definition include instructions for: 

defiboing a number of data objects. 

147. Tlie computer program product of claim 139 wherein the data object is a 
micropayment token. 

148. The computer program product of claim 147 wherein the micropayment token is a 
selected micropayment token. 
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149. The computer program product of claim 147 wherein the micropayment token is an 
unselected micropayment token. 

150. The computer program product of claim 139 wherein the data object is an offer 
package. 
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151. A verification method comprising: 

receiving a hashed, multi-level, data object, wherein the hashed, multi-level, 
data object includes one or more hashed, non-target data objects; 

receiving one or more sequential data keys, wherein each sequential data 
key corresponds to a hashed, non-target data object at a unique level within the 
hashed, multi-level, data object; 

receiving a non-hashed, target data object; 

hashing the non-hashed, target data object to generate an N*^ level hashed 
data object; 

grouping the N**" level hashed data object with an N^^ level, sequential data 
key to generate an N*^ level object/key pair; and 

hashing the N^^' level object/key pair to generate an N^*'"**^ level hashed data 

object; 

wherein grouping the level hashed data object and hashing the N* level 
object/key pair are repeated for each sequential data key. 

152. The method of claim 151 wherein the hashed, multi-level, data object is an 
encrypted, hashed, multi-level, data object, the method further comprising: 

decrypting the encrypted, hashed, multi-level, data object to generate a 
decrypted, hashed, multi-level, data object. 

153. The method of claim 1 52 further comprising: 

comparing the decrj'pted, hashed, multi-level, data object to the 
highest-level hashed data object generated to determine the validity of the hashed, 
' multi-level data object. 

154. The method of claim 151 wherein the non-hashed, target data object is a 
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micropayment token. 

155. The method of claim 154 wherein the micropayment token is a selected 
micropayment token. 

156. The method of claim 154 wherein the micropayment token is an unselected 
micropayment token. 

157. The method of claim 151 wherein the non-hashed, target data object is an offer 
package. 
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158. A computer program product residing on a computer, readable medium having a 
plurality of instructions stored thereon which, when executed by the processor, cause that 
processor to: 

receive a hashed, multi-level, data object, wherein the hashed, multi-level, 
data object includes one or more hashed, non-target data objects; 

receive one or more sequential data keys, wherein each sequential data key 
corresponds to a hashed, non-target data object at a unique level within the hashed, 
multi-level, data object; 

receive a non-hashed, target data object; 

hash the non-hashed, target data object to generate an N^*" level hashed data 

object; 

group the N*^' level hashed data object with an N*^ level, sequential data key 
to generate an N^^ level object/key pair; and 

hash the 'if' level object/key pair to generate an N*^"**^ level hashed data 

object; 

wherein grouping the N*^ level hashed data object and hashing the level 
object/key pair are repeated for each sequential data key. 

159. The computer program product of claim 158 wherein the hashed, multi-level, data 
object is an encrjpted, hashed, multi-level, data object, the computer program product 
further comprising instructions for: 

decrypting the encrypted, hashed, multi-level, data object to generate a 
decrypted, hashed, multi-level, data object 

160. The computer program product of claim 159 further comprising instructions for: 

comparing the decrypted, hashed, multi-level, data object to the 
highest-level hashed data object generated to determine the validity of the hashed, 
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multi-level data object, 

161. The computer program product of claim 158 wherein the non-hashed, target data 
object is a micropayment token. 

162. The computer program product of claim 161 wherein the micropayment token is a 
selected micropayment token. 

1 63 . The computer program product of claim 161 wherein the micropayment token is an 
unselected micropayment token. 

164. The computer program product of claim 158 wherein the non-hashed, target data 
object is an offer package. 
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165 . A secure payment processing system comprising: 

at least one secure module; and 
at least one non-secure module; 

wherein a plurality of tokens are transferred between the at least one secure 
module and the at least one non-secure module; 

wherein at least one of the modules executes a micropayment selection 
protocol that selects one or more, but not all, of the tokens for processing from the 
plurality of tokens. 

166. The system of claim 165 wherein the at least one secure module includes a cPSP 
module. 

167. The system of claim 165 wherein the at least one secure module includes an mPSP 
module. 

168. The system of claim 165 wherein the at lesist one non-secure module includes a 
consumer agent module. 

169. The system of claun 165 wherein the at least one non-secure module includes an 
ojBfer development module. 

170. The system of claim 165 wherein the at least one non-secure module includes a 
PCS module. 

171. ' The system of claim 165 wherein the micropayment selection protocol establishes 
payment for a transaction T, the protocol comprising: 

A. a first party deriving from T a data string C related to T, and causing a second 
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party to receive at least a portion of said data string C; 

B. the second party associating with said at least a portion of C an item V, 
wherein V is substantially unpredictable by the first party; 

C. the second party determining whether V satisfies a property P, and if so, the 
second party causing a third party to receive information I enabling the third party 
to verify whether V satisfies said property P; 

D. the third party, upon receiving I, verifying whether V satisfies said property P; 
and 

E. the third party causing a fourth party to receive an amount A, only if V 
satisfies said property P. 

172. The system of claim 165 wherein the micropayment selection protocol allows a 
user U to establish payment to a merchant M for a transaction T having a transaction value 
Tv, the protocol comprising: 

A. the user establishing a public key and a corresponding secret key for a first 
digital signature scheme, and deriving firom T a data string C = SIGru(T) to create an 
electronic check containing C, wherein SIGu(T) represents the digital signature of 
the user U for the transaction T in said first digital signature scheme; 

B. the user causing the merchant to receive said data string C; 

C. the merchant establishing a public key and a corresponding secret key for a 
second digital signature scheme, and associating with said data string C an item V = 
SIGm(C), wherein SIGk^CC) represents the digital signature of the merchant M for 
said data string C in said second digital signature scheme; 

D. the merchant computing the value F(V)=F(SIGiit4(C)), where F represents a 
public fimction that operates on a bit string to output a number between 0 and 1; 

E. the merchant comparing F(SIGm(C)) with a constant s to determine whether 
F(V) < s, and if so, causing a bank to obtain said pubUc key of the merchant; 
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R the bank using said public key of the merchant to verify that F(SIGm(C)) <s; 
and 

G. only if F(SIGm(C)) < s, the bank causing the merchant to receive an amount 
A=[Tv*l/s]; 

wherein s is a constant greater than 0 and less than 1, and represents the 
probability that the electronic check be selected for presentation to the bank. 

173. The system of claim 165 wherein the micropayment selection protocol establishes 
payment for a transaction T, the protocol comprising: 

A. a first paity receiving fi:om a second paity at least a portion of a data string 
C, wherein said data string C is related to T; 

B. the fu-st party associating with said at least a portion of C an item V, wherein 
V is substantially unpredictable b)' the second party; and 

C- the first party determining whether V satisfies a property P, and only if so, 
the first party causing a third party to receive information I enabling the third party 
to verify whether V satisfies said property P, thereby enabling the third party to 
cause a fourth party to receive an amount A upon verification that V satisfies P. 

174. The system of claim 165 wherein the micropayment selection protocol establishes 
payment for a transaction T, the protocol comprising: 

A. a first party receiving firom a second party infomiation I enabling the first 
part3^ to verify that an item V satisfies a property P; 

wherein said item V is associated with at least a portion of a data string C 
derived fi-om T by a third party and 

wherein V is substantial^ impredictable by said third party; 

B. the first party, upon receiving I, verifying whether V satisfies said property 
P; and 
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C. the first party causing a fourth party to receive an amount A, only if V 
satisfies said property P. 

175. The system of claim 165 wherein the micropayment selection protocol establishes 
payment for a transaction T characterized in part by a time t, the protocol comprising: 

A. a first party deriving firom T a data string C related to T, wherein C includes 
information IN regarding said time t; 

B. the first party causing a second party to receive at least a portion of said data 
string C, wherein said at least a portion of C includes information IN; 

C. the second party associating with said at least a portion of C an item V, 
wherein V is substantially unpredictable by the first party; 

D. the second party determining whether V satisfies a property P, and if so, the 
second party at time t' causing a third party to receive information IN and 
information I enabling the third party to verify whether V satisfies said property P; 

E. the third party, upon receiving I, verifying whether V satisfies said property 
P;aiid 

F. the third party causing a fourth party to receive an amount A, only if: 

a) V satisfies said property P, and 

b) |t' - 1( is less than a predetermined time interval. 

176. The system of claim 165 wherein the micropayment selection protocol establishes 
payment for a transaction T, the protocol comprising: 

A. a first party deriving firom T a data string C related to T, and causing a 
second party to receive at least a portion of said data string C; 

B. the second partj'^ detemiining whether a property P holds between said at 
least a portion of C and a quantity Q depending on C, wherein Q is substantially 
impredictable by the first party, and if so, the second party causing a third party to 
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receive information I enabling the third party to verify that said property P is 
satisfied; 

C, the third party, upon receiving I, verifying whether said property P is 
satisfied; and 

D. only upon verifying that said property P holds between said at least a 
portion of C and Q, the third party causing a fourth party to receive an amount A. 

177. The system of claim 165 wherein the micropayment selection protocol estabhshes 
payment for a transaction T characterized in part by a time t, the protocol comprising: 

A. a first party deriving fi-om T a data string C related to T; 

B. a second party deriving a sequence of values VLi associated with a 
sequence of times tf (i = 1, . . . , n), wherein for at least one integer m greater than 1 
and less than n, |t - tm| is less than a predetermined amoimt; 

C. the first party causing the second party to receive at least a portion of said 
data string C, wherein said portion includes information regarding the time t of said 
transaction T; 

D. the second party determining whether a property P holds between said 
portion of C, and one of said value VLm associated with t^, and a quantity Q 
depending on VLm; 

' E. if P holds, the second party causing a third party to receive information I 
enabling the third party to verify that said property P is satisfied; 
R the third party, upon recei\Tng I, verifying whether Q satisfies P; ajid 
G. the third party causing a fourth party to receive an amount A, only if Q 
satisfies said property P. 

178. The system of claim 165 wherein the micropayment selection protocol establishes 
payment for a transaction T characterized in part by a transaction t, the protocol 
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comprising: 

A. a first party deriving firom T a data string C related to T, wherein C includes 
information regarding t; 

B. a second party deriving a sequence of values Vj associated with a sequence 
of time units tj (i = 1, . . . , n); 

wherein each pair of adjacent time units ti+i and U defines a time interval AU 
— ti-fi- ti; and 

wherein for at least an integer m greater than 1 and less than n, said time t is 
within the time interval Atn,; 

C. at the beginning of said time interval At^, the second party deriving a value 
Qm associated with Vm, wherein Qm is substantially unpredictable by the first party; 

D. during said time interval Atm: 

a) the first party causing the second party to receive at least a portion of 

c; 

b) the second party determining whether a property P holds between 
said portion of C and Qm, and if so, the second party causing a third party to 
receive information I enabling the third party to verify that said property P 
is satisfied; 

E. the third party, upon receiving I, verifying whether Q satisfies P; and 

R the third party causing a fourth party to receive an amount A, only if Q 
satisfies said property P. 

179. The system of claim 165 wherein the micropayment selection protocol establishes 
pajment for a transaction T characterized in part by a time t, the protocol comprising: 

A. a first party deriving fi-om T a data string C related to T, wherein C includes 
information F regarding t; 

B. a second party deriving a sequence of values Xj (i = 0, 1, . . . , n) associated 
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with a sequence of time values ti (i = 0, 1, . . . , n), and making xq public; 

wherein Xj = H(Xi+i) for i = 0, 1, . . . , n-1, where H is a one-way hash 
function; 

wherein each pair of adjacent time values ti+i and t,- defines a time interval 
Ati = ti+i - tj; and 

wherein for at least an integer m greater than 1 and less than n, said time t is 
the time interval Atn,; 

C. during said time interval At^, the first party causing the second party to 
receive at least a portion of C, wherein said portion includes F; 

D. during said time interval Atm, the second party determining whether a 
property P holds between and said portion of C, and if so, the second party 
causing a third party to receive infonnation I enabling the third party to verify that 
said property P is satisfied; 

E. the fliird party, upon receiving I, verifying whether satisfies P; and 

R the third party causing a fourth party to receive an amoirnt A, only if Q 
satisfies said propertj' P. 

180. The system of claim 165 wherein the micropayment selection protocol establishes 
payment for a transaction T characterized in part by a time t, the protocol comprising: 

A. a first party receiving firom a second part>' at time f information I enabling 
the first party to verify that an item V satisfies a property P; 

wherein said item V is associated v^dth at least a portion of a data string C 
that is derived firom T by a third party and that includes information regarding t; and 
whereiu V is substantially impredictable by said third part}'^; 

B. the first party, upon receiving I, verifying whether V satisfies said property 
P; and 

C. the first party causing a fourth party to receive an amount A, only if: 
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a) V satisfies said property P; and 

b) |t' - 1| is less thaa a predetermined amount, 

181. The system of claim 165 wherein the micropayment selection protocol establishes 
payment for a transaction T characterized in part by a time t, the protocol comprising: 

A. a first party receiving firom a second party at least a portion of a data string 
C, wherein said data string C is related to T, and wherein said portion of C includes 
infomiation on t; 

B. tlae first party associating with said at least a portion of C an item V, wherein 
V is substantially unpredictable by the second party; and 

C. the first party determining whether V satisfies a property P, and if so, the 
first party at a time t* causing a tliird party to receive infomiation I enabling tlie third 
party to verify whether V satisfies said property P, thereby enabling the third party 
to cause a fourth party to receive an amormt A, provided that 

a) V satisfies P; and 

b) 1 1' - 1 1 is less than a predetermined amount. 

182 The system of claim 165 wherein the micropayment selection protocol establishes 
payment for a pluraUty of n transactions Ti, T2, . . • Ti, . . . Tn, wherein an index i, between 
1 and n, can be associated with each Ti, and wherein each transaction Ti is characterized in 
part by a transaction value TVi, the protocol comprising: 

A. a first party using a probabilistic payment scheme to generate a check Ci for 
each transaction Ti and causing a second party to receive said Q, wherein Q 
includes an indication of the index i; 

B. the second party selecting the checks Cj (1 < j < n ) that are payable ki a 
manner that prevents the first party from predicting in advance which checks Cj 
will be selected to be payable; 
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C. the second party causing a third party to receive information Ij enabling the 
third party to verify that a selected check Cj is payable; 

D. the third party, in response to receipt of Ij, verifying that a selected check Q 
is payable; and • ?^ 

E. only if Cj is payable, a fifth party causing a fourth party to receive a credit 
amount CRj, and causing the first party to be debited by a debit amount Dj so that, 
for all index j between 1 and n, and for any selection of payable checks, 
D=Di+D2+...+Dj is no greater than TVagg = TVi + TV2 + . . . +TVj. 

183. The system of claim 165 wherein the micropayment selection protocol establishes 
payment for a plurality of n transactions Ti, T2, . . . Ti, . . . Tn, wherein an index i, between 
1 and n, can be associated with each Ti, and wherein each transaction Ti is characterized in 
part by a transaction value TVi, the protocol comprising: 

A. a first party deriving fi-om each transaction T^ a data string Q related to Ti, 
and causing a second party to receive said data string Ci; 

B. the second party associating with each data string Ci an item Vi, wherein Vj 
is substantially unpredictable by the first partjr, 

C. the second party determining whether Vi satisfies a property Pi, and if so, 
the second party causing a third party to receive information Ij enabling the third 
party to verify whether Vi satisfies said property Pi; 

D. the third party, in response to receipt of li, verifying whether Vj satisfies said 
property Pj; and 

E. only if Vi satisfies said property Pi, a fifth party causing a fourth party to 
receive a credit amount CRi, and causing the first party to be debited by a debit 
amount Di; 

wherein said debit amount Di is less flian or equal to said credit amount CR^. 
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184. The system of claim 165 wherein the micropayment selection protocol pays for a 
plurality of equal-valued transactions Ti, T2, . . . Tj, . . . Tn, each having a value TV, the 
protocol comprising: 

A. a first party deriving fi-om each transaction T^ a data string Ci related to Ti, 
and causing a second party to receive said data string Ci; 

wherein each data string Ci comprises a progressive serial number Si, said 
serial number Si being sequentially ordered starting from 1 and being representative 
of a position of Ci relative to other data strings in an ordered succession of data 
strings Cj (j = 1, . . . , n); 

B. the second party associating with Q an item Vj, wherein Vi is substantially 
unpredictable by the first party; 

C. the second party determining whether a property Pi holds between Ci and Vj, 
and if so, the second party causing a third party to receive information li enabling 
the third party to verify whether Vi satisfies Pj; 

D. the third party verifying whether Vi satisfies Pi; and only if Vi satisfies 
Pi: 

a) a fifth party determining the value of S^ax, whereia S^ax represents 
the largest of any serial number Sk contained in Ck for which: 

i) 1 <k:<n; 

ii) Ck is received by seccmd party before receiving Q; 

iii) the third party has verified that Vk satisfies Pk; and 

iv) said first party has been debited by a nonzero amount Dk; 

b) said fifth party causing a fourth party to receive a credit amount CR; 
and 

c) said fifth party causing the first party to be debited by a debit 
amount Di, where Di is given by: 

(Si-Sn^) *TV 
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185. The system of claim 165 wherein the micropayment selection protocol allows a 
user to establish payment to a merchant M for a plurality of transactions Ti (i = 1, . . . , n) 
having transaction values TVi (i = 1, ... , , n), the protocol comprising: 

A. the user U establishing a public key and a corresponding secret key for a 
first digital signature scheme, and deriving firom each Ti a data string C\ = SIGu(Ti) 
and creating an electronic check CHi that contains Ci and a serial number Sj; 

wherein SIGu(TO represents the digital signature of the user Ui for the 
transaction T,- in said first digital signature scheme; 

wherein Sj is a progressive serial number representative of an order of said 
data string Ci relative to the other data strings in an ordered succession of data 
strings Cj Q = 1, • . . , n) derived by said first party; 

B. the user U causing the merchant M to receive said electronic check CHj 
containing Q and Si; 

C. the merchant M establishing a pubhc key and a corresponding secret key for 
a second digital signature scheme, and associating with said data string Q an item 
Vi = SIGmCQ), wherein SIGmCC,-) represents the digital signature of the merchant M 
/or said data string Ci in said second digital signature scheme; 

D. the merchant M computing the value F(Vi)=F(SIGM(Ci)), where F 
represents a public fixnction that operates on a bit string to output a number between 
Oand 1; 

E. the merchant M comparing F(SIGM(Ci)) with a constant s (0 < s < 1) to 
determine whether F(Vi) < s, and if so, causing a bank to obtain said public key of 
the merchant M; 

F. the bank using the merchant's pubUc key to verify that FCSIGmCQ)) <s; and 
G only if F(SIGM(Ci)) < s, 

a) a fifth party determining the value of Smax, wherein Smax represents 

94 



wo 2004/068293 



PCTAJS2004/001845 



the largest serial number Sj contained in any CHj in said ordered succession 
upon which payment was made; 

b) ..^ said fifth party causing a fourth party to receive a credit amount CR; 
and 

c) said fifth party causing the first party to be debited by a debit 
amoimt Dj. 

1S6. The system of claim 165 wherein the micropayment selection protocol estabhshes 
payment for a plurality of n transactions Ti, T2, . . . , Tj, . . . , Tn, wherein an index i, 
between 1 and n, can be associated with each Ti, and wherein each transaction T\ is 
characterized in part by a transaction value TVj, the protocol comprising: 

A. a first party receiving fi-om a second party at least a portion of a data string 
Ci for each Ti, wherein each data string Ci is generated firom Ti using aprobabiUstic 
payment scheme, and wherein each Ci includes an indication of the index i; 

B. the first party selecting the checks Cj (j less than or equal to n and greater 
than or equal to 1) that are payable in a manner that prevents the first party firom 
predicting in advance which checks Cj will be selected as payable; 

C. for each selected check Cj, the first party causing a third party to receive 
information Ij enabling the third party to verify that the selected check Cj is indeed 
payable, thereby enabling the third party, upon verification that Cj is payable, to 
cause a fourth party to receive a credit amoxmt CRj and the second party to be 
debited by a debit amoimt Dj so that, for all index j betv^^een 1 and n, and for any 
selection of payable checks Cj, D = Di + D2 + . . . Dj is no greater than TVagg = TVi 
+ TV2 + ...+TVj. 

187. The system of claim 165 wherein the micropajonent selection protocol establishes 
payment for a plurahty of n transactions Ti, T2, . . . , Ti, . . . , Tn, wherein an index i. 
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between 1 and n, can be associated with each Ti, and wherein each transaction Tj is 
characterized in part by a transaction value TVj and can be represented by a corresponding 
data string Cj, the protocol comprising: 

A. a first party receiving from a second party information Ij enabling the first 
party to verify that a check Cj is payable; 

wherein said check Cj is selected by the second party from a plurality of 
checks Ci (i = 1, . . . , n) derived by a third party from a corresponding one of said 
pliirality of transactions Tj (i = 1 , . . . , n); and 

wherein the selection of said check Cj is substantially unpredictable by said 
third party; 

B. the first party, upon receiving Ij, verifying whether Cj is indeed payable; and 

C. the first party causing a fourth party to receive a credit amount CRi, and 
causing the third party to be debited by a debit amount Di, 

188. The system of claim 165 wherein the micropayment selection protocol establishes 
payment for a plurality of n transactions Ti, T2, . . . Tj, . . . Tn, wherein each transaction Tj 
is characterized in part by a transaction value TVj that is a multiple of a unit value UV, the 
protocol comprising: 

A. a first party deriving from each transaction Ti a data string Ci corresponding 
to Ti, and causing a second party to receive Ci; 

wherein each data string Q includes information on said integer index i and 
said value TVi of Ti in the form of a vector (Si, Si + Vj-l); 

wherein for all i betv/een 1 and n, Sj is a progressive serial number that is 
sequentially ordered and that is representative of a position of Ci relative to other 
data strings in an ordered succession of data strings Cj 0 = 1> • • • ? n); and 

wherein Vi is an integer depending on i and indicative of the value TVi of Ti, 
and is given by Vi = TVi / (UV) ; 
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B. the second party selecting the checks Q (1 < j < n ) that are payable in a 
maimer that prevents the first party from predicting in advance which checks Q 
wiil'he selected to be payable; 

C. the second party causing a third party to receive infonnation Ij enabling the 
third party to verify that a selected check Cj is payable; 

D. the third party, in response to receipt of Ij, verifying that a selected check Cj 
is payable; and 

E. only if Cj is payable: 

a) a fifth party determining the value of Smax, 

wherein max is an integer such that 1 < max < i < n, and Vj^kuc = 
TVniax/(IAO;and 

wherein Smax represents the largest of any serial number Sk (1 ^ k < n) 
contained in Ck for which: 

i) Ck is received by the second party before receiving Q; and 

ii) the third party has verified that Vk satisfies Pk; and 

iii) said first party was debited by a non-zero amount Dk, and 

b) said fifth party causing a fourth party to receive a credit amount CR; 
and 

c) said fifth party causing the first party to be debited by a debit 
amount Dj, where Di is given by: ( Si+ Vj - 1 - Smax ) * UV, 

189. The system of claim 165 wherein the micropayment selection protocol establishes 
payment for a plurality of n transactions Ti, T2, . . . Tj, . . . Tn, wherein an index i betv^'een 
1 and n is associated \^dth each Ti, and wherein each transaction Tj is characterized in part 
by a transaction value TVj that is an integral multiple of a imit value UV, the protocol 
comprising: 

A. a first party deriving from each transaction Tj a data string Ci corresponding 
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to Ti and causing a second party to receive Q; 

wherein each data string Ci includes information on said integer index i and 
said value TVi of Tj in the form of a vector (Si, Si + Vj - 1); 

wherein for all i between- 1 and n, Si is a progressive serial number that is 
sequentially ordered and that is representative of a position of Ci relative to other 
data strings in an ordered succession of data strings Q (j = 1, . , , ,n); and 

wherein v, is an integer depending on i and indicative of the value TVj of Tj, 
and is given by Vi = TVj / (UV); 

B. the second party associating with Q an item Vj, wherein Vi is substantially 
impredictable by the first party; 

C. the second party determining whether a property Pi holds between Ci and V i, 
and if so, the second party causing a third party to receive infomiation Ij enabling 
the third party to verify whether Vi satisfies Pi; 

D. the third party verifying whether Vi satisfies Pi; and only if Vi satisfies Pi: 

a) a fifth party determining the value of Smax, 

whereiu max is an integer such that 1 ^ max < i ^ n, and Vmax — 
TVmax/(UV);and 

wherein Sniax represents the largest of any serial number Sk (1 ^ k < n) 
contained in Ck for which: 

i) Ck is received by the second party before receiving Cij and 

ii) the third party has verified that Vk satisfies Pk; and 

iii) said first party was debited by a non-zero amoimt Dk, and 

b) said fifth party causing a fourth part>' to receive a credit amount CR; 
and 

c) said fifth party causing tlie first party to be debited by a debit 
amount Di, where Di is given by: ( Si + Vi - 1 - Sniax ) * UV. 
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190. The system of claim 165 wherein the micropayment selection protocol establishes 
payment for a plurality of n transactions Tj (i = 1, . . . , n), each transaction Ti having a value 
TVi, the protocol comprising: 

a. a first party deriving from each T,- a data string Cj related to Tj, and causing 
a second party to receive said data string Cj; 

b. the second party uniquely associating groups of said data strings C\ (i = 
1, . . . , n) mto m lists L^, where k = 1, . . . , m; 

wherein each list includes data strings C*^i, . . . , C^/k^ and 

wherein 2\==i /k= n; 

c. the second party committing to (k = 1, . . . , m), by computing a 
commitment CM^ for each L^, and causing a third party to receive CM'^ (k = 1 , . . . , 
m); 

d. the third party, iu response to receipt of CM^ (k = 1 , . . . , m), selecting one or 
more integer indices ii, i2, . - . ir. and causing the second party to receive said indices 
ii, i2, . - . ir. wherein 1 < ir < m; 

e. in response to receipt of said indices ii, i2, . . . in the second party 
de-committing CM'\ CM'^, . . CM^^ thereby revealing V\ . . L''^ to the third part}^; 
and 

f. a fifth party causing a fourth party to receive a credit amount CR^ and 
causing the first party to be debited by a debit amount D. 

191. The system of claim 165 wherein the micropayment selection protocol establishes 
payment for a plxirality of n transactions Ti, . . . , Ti, . . . , Tn, each transaction T, having a 
value TVi, the protocol comprising: 

A. for each Ti, a first party receiving firom a second part}' a data string Q 
derived firom Ti; 

B. the first party uniquely associating groups of said data strings Ci (i = 1, . . . , 
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n) into m lists where k = 1, . . . , m; 

wherein each hst includes data strings C^i, . . . , C^/k, and 
wherein ^'"k = i = 

C. the first party committing to (k = 1 , . . . , m), by computing a commitment 
CM^ for each L'', and causing a third party to receive CM^ (k == 1, , . , m), thereby 
enabling the third party to select one or more integer indices ii, ia, . • . ir, wherein 1 < 
ir ^ m; 

D. upon receipt of said indices ii, ia, . . , ir, the first party de-committing CM^\ 
CM'^. . . CM^ thereby revealing L'', . . L*'" to the third party and enabling the third 
party to cause a fourth party to receive a credit amount CR, and the second party to 
be debited by a debit amount D. 

192. The system of claim 165 wherein the micropayment selection protocol establishes 
payment for a plurality of n transactions Ti, . . . , Tj, . . . , Tn, wherein each transaction Ti has 
a value TVi and can be represented by a corresponding data string Q deriA^ed firom Ti, and 
wherein groups of said data strings Q (i = 1, . . . , n) can be uniquely associated into m lists 
L'^Ck = 1, . . . , m), each Ust includes data strings C^i, . . . , C\ 1 k = n), the 

protocol comprising: 

A. a first party receiving firom a second party a commitment CM*^ for each of 
the m lists (k = 1, . . . , m); 

B. the first party, upon receiving CM^ (k = I, . . . , m), selecting one or more 
integer indices ii, i2, • . • ir, wherein 1 < ir < m, and causing the second part^'^ to 
receive said indices ii, i25 . . . ir, thereby enabling the second party to de-commit 
CM'\ CM^, . . CKf' so as to revealing V\ . . L^' to the first party; 

C. the first party causing a third party to receive a credit amount CR, and a 
fourth party to be debited by a debit amount D. 
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193. A secure payment processing system comprising: 

at least one secure module; and 
at least one non-secure module; 

wherein a plurality of tokens are transferred between the at least one secure 
module and the at least one non-secure module; 

wherein at least one of the modules includes a computer program product 
residing on a computer readable medium having a plurality of instructions stored 
thereon which, when executed by the processor, cause that processor to select one 
or more, but not all, of the tokens for processing from the plurality of tokens. 

194. The system of claim 193 wherein the at least one secure module includes a cPSP 
module. 

195. The system of claim 193 wherein the at least one secure modvde includes an mPSP 
module. 

196. The system of claim 193 wherein the at least one non-secure module includes a 
consumer agent module. 

197. The system of claim 193 wherein the at least one non-secure module includes an 
offer development module. 

198. The system of claim 193 wherein the at least one non-seciure module includes a 
PCS module. 

199. The system of claim 193 wherein the computer program product establishes 
payment for a transaction T, wherein the instructions for selecting one or more 
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micropayment tokens include instructions for: 

A. a first party deriving firom T a data string C related to T, and causing a second 
party to receive at least a portion of said data string C; 

B. the second party associating with said at least a portion of C an item V, 
wherein V is substantially unpredictable by the first party; 

C. the second party determining whether V satisfies a property P, and if so, the 
second party causing a third party to receive information I enabling tlie third party 
to verify whether V satisfies said property P; 

D. the third party, upon receiving I, verifying whether V satisfies said property P; 
and 

E. the third party causing a fourth party to receive an amount A, only if V 
satisfies said property P. 

200. The system of claim 193 wherein the computer program product allows a user U to 
estabhsh payment to a merchant M for a transaction T having a transaction value Ty, 
wherein the instructions for selecting one or more micropayment tokens include 
instractions for: 

A. the user establishing a public key and a corresponding secret key for a first 
digital signature scheme, and deriving from T a data string C = SIGu(T) to create an 
electronic check containing C, wherein SIGu(T) represents the digital signature of 
the user U for the transaction T in said first digital signature scheme; 

B. the user causing the merchant to receive said data string C; 

C. the merchant establishing a public key and a corresponding secret key for a 
second digital signature scheme, and associating with said data string C an item V = 
SIGm(C), wherein SIGm(C) represents the digital signature of the merchant M for 
said data string C in said second digital signature scheme; 

D. the merchant computing the value F(V)=F(SIGm(C)), where F represents a 
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public function that operates on a bit string to output a number between 0 and 1; 
E. the merchant comparing F(SIGm(C)) with a constant s to detennine whether 

F(V) < s, and if so, causing a bank to obtain said public key of the merchant; 
E the bank using said public key of the merchant to verify that F(SIG^4CQ) 
and 

G only if F(SIGm(C)) < s, the bank causing the merchant to receive an amount 

A=[Tv*l/s]; 

wherein s is a constant greater than 0 and less than 1, and represents the 
probability that the electronic check be selected for presentation to the bank. 

201. Tlie system of claim 193 wherein the computer program product establishes 
payment for a transaction T, wherein the instructions for selecting one or more 
micropayment tokens include instmctions for: 

A. a first party receiving firom a second party at least a portion of a data string 
C, wherein said data string C is related to T; 

B. the first party associating with said at least a portion of C an item V, wherein 
V is substantially unpredictable by the second party; and 

C. the first party determining whetlier V satisfies a property E, and only if so, 
the first party causing a third party to receive information I enabling the third party 
to verify whether V satisfies said property P, thereby enabling the third party to 
cause a fourth partj'^ to receive an amount A upon verification that V satisfies P. 

202. The system of claim 193 wherein the computer program product establishes 
payment for a transaction T, wherein the instmctions for selecting one or more 
micropajonent tokens include instructions for: 

A. a first party receiving fi:om a second party information I enabling the first 
party to verify that an item V satisfies a property P; 
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wherein said item V is associated with at least a portion of a data string C 
derived from T by a third party, and 

wherein V is substantially unpredictable by said third party; 

B. the flJrst part}', upon receiving I, verifying whether V satisfies said property 
P; and 

C. the first party causing a fourth party to receive an amount A, only if V 
satisfies said property P. 

203. The system of claim 193 wherein the computer program product establishes 
payment for a transaction T characterized in part by a time t, wherein the instractions for 
selecting one or more micropajonent tokens include instructions for: 

A. a first party deriving from T a data string C related to T, wherein C includes 
information IN regarding said time t; 

B . the first party causing a second party to receive at least a portion of said data 
string C, wherein said at least a portion of C includes information IN; 

C. tiie second party associating with said at least a portion of C an item V, 
wherein V is substantially unpredictable by the first party; 

D. the second party determining whether V satisfies a property P, and if so, the 
second party at time f causing a third party to receive information IN and 
information I enabling the third party to verify whether V satisfies said property P; 

E. the third party, upon receiving I, verifying whether V satisfies said property 
P;and 

R the third part)^ causing a fourtli part}' to receive an amount A, only if: 

a) V satisfies said property P, and 

b) |t* - 1| is less than a predetermined time interval. 

204. The system of claim 193 wherein the computer program product establishes 
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payment for a transaction T, wherein the instructions for selecting one or more 
micropayment tokens include instmctions for: 

A. a first party deriving from T a data string C related to T, and causing a 
second party to receive at least a portion of said data string C; 

B. the second paity determining whether a property P holds between said at 
least a portion of C and a quantity Q depending on C, wherein Q is substantially 
unpredictable by the first party, and if so, the second party causing a third party to 
receive information I enabling the third party to verify that said property P is 
satisfied; 

C. the third party, upon receiving I, verifying whether said property P is 
satisfied; and 

D. only upon verifying that said propert)^ P holds between said at least a 
portion of C and Q, the third partj^ causing a fourth party to receive an amount A. 

205. The system of claim 193 wherein the computer program product establishes 
payment for a transaction T characterized in part by a time t, wherein the instmctions for 
selecting one or more micropayment tokens include instructions for: 

A. a first party deriving from T a data string C related to T; 

B. a second party deriving a sequence of values VLj associated with a 
sequence of times tj (i = 1, , . . , n), wherein for at least one integer m greater than 1 
and less than n, |t - tm| is less than a predetermined amount; 

C. the first party causing the second party to receive at least a portion of said 
data string C, wherein said portion includes infomiation regarding the time t of said 
transaction T; 

D. the second party determining whether a property P holds between said 
portion of C, and one of said value VLm associated witli t^, and a quantity Q 
depending on VLm; 
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B. if P holds, the second party causing a third party to receive iBfonnation I 

enabling the third party to verify that said property P is satisfied; 

R the third party, upon receiving I, verifying whether Q satisfies P; and 

G. the third party causing a fourth party to receive an amount A, only if Q 

satisfies said property P. 

206. The system of claim 193 wherein the computer program product establishes 
payment for a transaction T characterized in part by a transaction t, whereiii the instructions 
for selecting one or more micropayment tokens include instructions for: 

A. a first party deriving from T a data string C related to wherein C includes 
information regarding t; 

B. a second party deriving a sequence of values V; associated with a sequence 
of time units ti (i = 1, . . . , n); 

wherein each pair of adjacent time units tj+i and tj defines a time interval Atj 
= ti+i- tii and 

wherein for at least an integer m greater than 1 and less than n, said time t is 
within the time interval Atm; 

C. at the beginning of said time interval Atm, the second party deriving a value 
Qm associated with Vm, wherein is substantially unpredictable by the first party; 

D. during said time interval Atm: 

a) the first party causing the second party to receive at least a portion of 
C; 

b) "the second party detemiining v/hether a property P holds between 
said portion of C and Qm, and if so, tlie second party causing a third part}^ to 
receive infomiation I enabUng the tliird party to verif>^ that said property P 
is satisfied; 

E. the third part}^, upon receiving I, verifying whether Q satisfies P; and 
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F. the third party causing a fourth party to receive an amount A, only if Q . 
satisfies said property P. . 

207. The system of claim 193 wherein the computer program product estabhshes 
payment for a transaction T characterized in part by a time t, wherein the instructions for 
selecting one or more micropayment tokens include instructions for: 

A. a first party deriving from T a data string C related to T, wherein C includes 
information F regarding t; 

B. a second party deriving a sequence of values x,- (i = 0, 1, . . . , n) associated 
with a sequence of time values ti (i = 0, 1, . . . , n), and making Xo public; 

wherein Xi = H(Xi+i) for i = 0, 1, , , . , n-1, where H is a one-way hash 
fimction; 

wherein each pair of adjacent tune values ti+i and ti defines a time interval 
A^ = ti+i -ti;and 

wherein for at least an integer m greater than 1 and less than n, said time t is 
the time interval Atm; 

C. during said time interval At^, the first party causing the second party to 
receive at least a portion of C, wherein said portion includes F; 

D. during said time interval Atm, the second party determining whether a 
property P holds between Qm and said portiion of C, and if so, the second party 
causing a third party to receive information I enabling the third party to verify that 
said property P is satisfied; 

E. the third party, upon receiving I, verifying whether Qm satisfies P; and 

R the third party causing a fourth party to receive an amount A, only if Q 
satisfies said property P. 

208. The system of claim 193 wherein the computer program product establishes 
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payment for a transaction T characterized in part by a time t, wherein the instructions for 
selecting one or more micropayment tokens include instructions for: 

A. a first party receiving from a second party at time t' information I enabling 
the first party to verify that an item V satisfies a property P; 

wherein said item V is associated with at least a portion of a data string C 
that is derived from T by a third party and that includes information regarding t; and 
wherein V is substantially unpredictable by said third party; 

B. the first party, upon receivmg I, verifying whether V satisfies said property 
P; and 

C. the first party causing a fourth party to receive an amount A, only if: 

a) V satisfies said property P; and 

b) |t* - 1| is less than a predetermined amount. 



209. The system of claim 193 wherein the computer program product establishes 
payment for a transaction T characterized in part by a time t, wherein the instmctions for 
selecting one or more micropayment tokens include instructions for: 

A. a first party receiving from a second party at least a portion of a data string 
C, wherein said data string C is related to T, and wherein said portion of C includes 
information on t; 

B. the first party associating with said at least a portion of C an item V, wherein 
V is substantially xmpredictable by the second party; and 

C. the first party determining whether V satisfies a property' P, and if so, the 
first party at a. time t' causing a third party to receive information I enabling the third 
party to verifj^ whether V satisfies said property P, thereby enabling the third party 
to cause a fourth party to receive an amount A, provided that 

a) V satisfies P; and 

b) 1 1' - 1 1 is less than a predetermined amount. 
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210. The system of claim 193 wherein the computer program product estabhshes 
payment for a plurality of n transactions Ti, T2, . . . Ti, . . . Tn, wherein an index i, between 
1 and n, can be associated with each Ti, and wherein each transaction Ti is characterized in 
part by a transaction value TVi, wherein the instructions for selecting one or more 
micropayment tokens include instructions for: 

A. a first party using a probabilistic payment scheme to generate a check Q for 
each transaction Ti and causing a second party to receive said C,-, wherein Ci 
includes an indication of the index i; 

B. the second party selecting the checks Q (1 < j < n ) that are payable in a 
manner that prevents the first party fi:om predicting in advance which checks Q 
will be selected to be payable; 

C. the second paxty causing a third party to receive information Ij enabling the 
third party to verify that a selected check Q is payable; 

D. the third party, in response to receipt of Ij, verifying that a selected check Cj 
is payable; and 

E. only if Q is payable, a fifth party causing a fourth party to receive a credit 
amount CRj, and causing the first party to be debited by a debit amount Dj so that, 
for all index j between 1 and n, and for any selection of payable checks, 
D=Di+D2+...+Dj is no greater than TVagg = TVi + TV2 + . . . +TVj. 

211. The system of claim 193 wherein the computer program product estabhshes 
pajonent for a plurality of n transactions Ti, T2, . - . Ti, . , . Tn, wherein an index i, between 
1 and n, can be associated with each Ti, and wherein each transaction T\ is characterized in 
part by a transaction value TVi, wherein the instructions for selecting one or more 
micropayment tokens include instructions for: 

A. a fijrst party deriving fi:om each transaction Tj a data string C\ related to Tj, 
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and causing a second party to receive said data string Q; 

B. the second party associating with each data string C\ an item Vj, wherein Vi 
is substantially unpredictable by the first party; 

C. the second party determining whether Vi satisfies a property Pj, and if so, 
the second party causing a third party to receive information I\ enabUng the third 
party to verify whether Vi satisfies said property Pj; 

D. the third party, in response to receipt of li, verifying whether Vj satisfies said 
property Pi; and 

E. only if Vi satisfies said property Pj, a fifth party causing a fourth party to 
receive a credit amount CRi, and causing the first party to be debited by a debit 
amount Di; 

wherein said debit amount Di is less than or equal to said credit amount CR,. 

212. The system of claim 193 wherein the computer program product pays for aplurality 
of equal-valued transactions Ti, T2, . . . Ti, . . . Tn, each having a value TV, wherein the 
instructions for selecting one or more micropayment tokens include instructions for: 

A. a first party deriving from each transaction Ti a data string Ci related to Tj, 
and causing a second party to receive said data string Q; 

wherein each data string Ci comprises a progressive serial nimiber Si, said 
serial number Si being sequentially ordered starting firom 1 and being representative 
of a position of Q relative to other data strings in an ordered succession of data 
strings CjO = l,...,n); 

B. the second party associating with Ci an item Vi, wherein Vi is substantially 

unpredictable by the first part}^; 

C. the second party determining whether a property Pi holds betv/een Ci and Vi, 
and if so, the second party causing a third party to receive information Ij enabling 
the third party to verify whether Vi satisfies Pi; 
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D. the third party verifying whether Vj satisfies Pi; and only if Vi satisfies 
Pi: 

a) a fifth party determining the value of S^ax, wherein Smax represents 
the largest of any serial number Sk contained in Ck for which: 

i) 1 <k<n; 

ii) Ck is received by second party before receiving Q; 

iii) the third party has verified that Vk satisfies Pk; and 

iv) said fnst party has been debited by a nonzero amount Dk; 

b) said fifth party causing a fourth party to receive a credit amount CR; 
and 

c) said fifth party causing the first party to be debited by a debit 
amount Di, where Di is given by: 

(Si-Sn^x) *TV. 

213. The system of claim 193 wherein the computer program product allows a user to 
establish payment to a merchant M for a plurality of transactions Ti (i = 1, . . . , n) having 
transaction values TVi (i = 1, . . , n), wherein the instructions for selecting one or more 
micropayment tokens include instructions for: 

A. the user U establishing a public key and a corresponding secret key for a 
first digital signature scheme, and deriving fi^om each Ti a data string Q = SIGu(Ti) 
and creating an electronic check CHi that contains Ci and a serial number S,-; 

v/herein SIGu(Ti) represents the digital signature of the user Ui for the 
transaction Ti in said first digital signature scheme; 

wherein S\ is a progressive serial number representative of an order of said 
data string Ci relative to the other data strings in an ordered succession of data 
strings Cj (j = 1, . , . , n) derived by said first party; 

B. the user U causing the merchant M to receive said electronic check CHi 
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containing Q and S\; 

C. tlie merchant M establishing a pubUc key and a corresponding secret key for 
a second digital signature scheme, and associating with said data string Ci an item 
Yi = SIGm(Q), wherein SIGmCCO represents the digital signature of the merchant M 
for said data string Ci in said second digital signature scheme; 

D. the merchant M computing the value . F(Vi)=F(SIGM(Ci)), where F 
represents a pubUc function that operates on a bit string to output a number between 
Oand 1; 

E. the merchant M comparing FCSIGmCQ)) with a constant s (0 < s < 1) to 
determine whether F(Vi) < s, and if so, causing a bank to obtain said public key of 
the merchant M; 

F. the bank using the merchant's public key to verify that F(SIGM(Ci)) <s; and 
G only if F(SIGM(Ci)) < s, 

a) a fifth party detemiining the value of Smax, wherein Snmx represents 
the largest serial number Sj contained in any CHj in said ordered succession 
upon which payment was made; 

b) said fifth party causing a fourth party to receive a credit amount CR; 
and 

c) said fifth party causing the first party to be debited by a debit 
amount Dj. 

214. The system of claim 193 wherein the computer program product establishes 
pajrment for a plurality of n transactions Ti, T2, . . . , Tf, . . . , Tn, wherein an index i, 
between 1 and n, can be associated v/ith each Ti, and wherein eaxh transaction Ti is 
characterized in part by a transaction value TVi, wherein the instructions for selecting one 
or more micropayment tokens include instructions for: 

A. a first party receiving firom a second party at least a portion of a data string 
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Ci for each Ti, wherein each data string Ci is generated from Ti using a probabilistic 
payment scheme, and wherein each Ci includes an indication of the index i; 
" B. the first party selecting the checks Cj (j less than or equal to n and greater 
than or equal to 1) that are payable in a manner that prevents the first party fi-om 
predicting in advance which checks Cj will be selected as payable; 
C. for each selected check Cj, the first party causing a third party to receive 
infomiation Ij enabling the third party to verify that the selected check Cj is indeed 
payable, thereby enabling the third party, upon verification that Cj is payable, to 
cause a fourth party to receive a credit amount CRj and the second party to be 
debited by a debit amount Dj so that, for all index j between 1 and n, and for any 
selection of payable checks Cj, D = Di + Da + . . . Dj is no greater than TVagg = TVi 

H-TV2H-. . .H-TVj. 

215, The system of claim 193 wherein the computer program product estabUshes 
payment for a plurality of n transactions Ti, T2, . . . , Ti, . . . , Tn, wherein an index i, 
between 1 and n, can be associated with each Tj, and wherein each transaction Ti is 
characterized in part by a transaction value TVj and can be represented by a corresponding 
data string Ci, wherein the instructions for selecting one or more micropayment tokens 
include instructions for: 

A. a first party receiving from a second party information Ij enabling the first 
party to verify that a check Cj is payable; 

wherein said check Cj is selected by the second party from a pluraUty of 
checks Ci (i = 1, . . . , n) derived by a third party from a corresponding one of said 
plurality of transactions Tj (i = 1, . . . , n); and 

wherein the selection of said check Cj is substantially unpredictable by said 
third party; 

B. the first party, upon receiving Ij, verifying whether Cj is indeed payable; and 
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C. the first party causing a fourth party to receive a credit amount CR,-, and 
causing the third party to be debited by a debit amount Dj, 

216, The system of claim 193 wherein the computer program product estabUshes 
payment for a plurality of n transactions Ti, T2, . . . Ti, . . . Tn, wherein each transaction Ti 
is characterized in part by a transaction value TV,- that is a multiple of a unit value UV, 
wherein tlie instructions for selecting one or more micropayment tokens include 
instructions for: 

A. a first party deriving from each transaction Ti a data string C,- corresponding 
to Ti, and causing a second party to receive Ci; 

wherein each data string Cj includes infomiation on said integer index i and 
said value TVi of Tj in the form of a vector (Si, Si + Vj-l); 

wherein for all i between 1 and n, Sj is a progressive serial number that is 
sequentially ordered and that is representative of a position of Q relative to other 
data strings in an ordered succession of data strings Cj (j == 1, . . . , n); and 

wherein Vj is an integer depending on i and indicative of the value TVi of Ti, 
and is given by Vi = TVj / (UV); . 

B. the second party selecting the checks Cj (1 < j < n ) that are payable in a 
manner that prevents the first party from predicting in advance which checks Cj 
will be selected to be payable; 

C. the second party causing a third party to receive information Ij enabling the 
third party to verify that a selected check Q is payable; 

D. the third party, in response to receipt of Ij, verifjdng that a selected check Q 
is payable; and 

E. only if Cj is payable: 

a) a fifth party determining the value of Smax, 

wherein max is an integer such that 1 < max < i < n, and Vmax = 
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TVmax/CUV);and 

wherein Smax represents the largest of any serial number Sk (1 < k < n) 
contained in Ck for which: 

i) Ck is received by the second party before receiving Q; and 

ii) the third party has verified that Vk satisfies Pk; and 

iii) said first party was debited by a non-zero amount Dkfand 

b) said fifth party causing a fourth paity to receive a credit amount CR; 
and 

c) said fifth party causing the first party to be debited by a debit 
amount Dj, where Dj is given by: ( Si + Vi - 1 - S™x ) * UV. 

217. The system of claim 193 wherein the computer program product establishes 
payment for a plurahty of n transactions Ti, T2, . . . Ti, . . . Tn, wherein an index i between 
1 and n is associated with each Tj, and wherein each transaction Ti is characterized in part 
by a transaction value TVi that is an integral multiple of a unit value UV, wherein the 
instructions for selecting one or more micropayment tokens include instmctions for: 

A. a first party derivmg fi-om each transaction Tj a data string C, corresponding 
to Ti and causing a second party to receive Q; 

wherein each data string Q includes information on said integer index i and 
said value TVi of Tj in flie form of a vector (Si. Si + Vi - 1); 

wherein for all i between 1 and n. Si is a progressive serial number that is 
' sequentially ordered and that is representative of a position of Q relative to other 
data strings m an ordered succession of data strings Cj 0 = 1, . . . , n); and 

wherein Vi is an integer depending on i and indicative of the value TVj of Tj, 
and is given by Vi = TVi / (UV); 

B. the second party associating with Q an item Vi, wherein Vi is substantially 
unpredictable by the first party; 
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C. the second party determining whether a property Pj holds between Q and Vi, 
and if so, the second party causing a third party to receive information li enabling 
the third party to verify whether V, satisfies Pi; 

D. the third party verifying whether Vj satisfies P^; and only if V,- satisfies Pj: 

a) a fifth party determining the value of Smax» 

wherein max is an integer such that 1 < max < i < n, and Vmax = 
TV^ax/(UV);and 

wherein Smax represents the largest of any serial number Sk (1 ^ k < n) 
contained in Ck for which: 

i) Ck is received by the second party before receiving d; and 

ii) the third party has verified that Vk satisfies Pk; and 

iii) said first party was debited by a non-zero amount Dk, and 

b) said fifth party causing a fourth party to receive a credit amount CR; 
and 

c) said fifih party causing the first party to be debited by a debit 
amount Di, where Dj is given hy: ( Si + Vj - 1 - Smax ) * UV. 

218. The system of claim 193 wherein the computer program product establishes 
payment for a plurality of n transactions Tj (i = 1 , . . . , n), each transaction Ti having a value 
TVi, wherein the instructions for selecting one or more micropayment tokens include 
instructions for: 

a. a first party deriving fi*om each T,- a data string Q related to Tj, and causing 
a second party to receive said data string Q; 

b. the second party uniquely associating groups of said data strings Q (i = 
1, . . . , n) into m lists L^, where k = 1, . . . , m; 

wherein each list includes data strings C^i, . . . , C'Vk, and 
wherein 2™k= i /k = n; 
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c. the second party committing to (k = 1, . . . , m), by computing a 
commitment CM'' for each L^, and causing a third party to receive CM^ (k = 1 , . . . , 
m); 

d. the third party, in response to receipt of CM^ (k = 1 , . . . , m), selecting one or 
more integer indices ii , i2, . . . ir. and causing the second party to receive said indices 
il, i2, . . . ir. wherein 1 < ir < m; 

e. in response to receipt of said indices ii, ia, . . . the second party 
de-committing CM*^ CM}\ . . CM^', thereby revealing V\ . . L^' to the thirdparty; 
and 

f. a fifth party causing a fourth party to receive a credit amount CR, and 
causing the first party to be debited by a debit amount D. 

219. The system of claim 193 wherein the computer program product establishes 
payment for aplurahty of n transactions Ti, . . . , Ti, . . . , Tn, each transaction Ti having a 
value TVi, wherein the instructions for selecting one or more micropayment tokens include 
instmctions for: 

A. for each Ti, a first party receiving from a second party a data string Q 
derived firom Ti; 

B. the first party uniquely associating groups of said data strings Q (i = 1, . . . , 
n) into m lists where k = 1, . . . , m; 

wherein each hst includes data strings C^i, . . . , C\y and 

wherein S"^ic=i 4= n; 

C. the first party committing to L^' (k = 1 , . . . , m), by computing a commitment 
CM^ for each L*', and causing a third party to receive CM*" (k = 1, . . . , m), thereby 
enabling the third party to select one or more integer uadices ii, i2, . - . ir, wherein 1 < 
ir^m; 

D. upon receipt of said indices ii, i2, . . . ir, the first party de-committing CM'\ 
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CM*^. . . CM'', thereby revealing V\ , . L'' to the third party and enabling the third 
party to cause a fourth party to receive a credit amount CR, and the second part>' to 
be debited by a debit amount D. 

220. The system of claim 193 wherein the computer program product establishes 
payment for a plurality of n transactions Ti, . . . , Tj, . . . , Tn, wherein each transaction T,- has 
a value TVj and can be represented by a corresponding data string Ci derived from T,*, and 
wherein groups of said data strings Ci (i = 1, . . . , n) can be uniquely associated into m lists 
L^(k = 1, . . . , m), each Ust includes data strings C^i, . . . , C^/k (S"^k- 1 k = n), wherein 
tlie instructions for selecting one or more micropayment tokens include instructions for: 

A. a first party receiving from a second party a commitment CM^ for each of 
the m lists Lk (k = 1, . . . , m); 

B. the first party, upon receiving CM^ (k = 1, . . . , m), selecting one or more 
integer indices ii, i2, . . . ir, wherein 1 < ir < m, and causing the second party to 
receive said indices ii, i2, . . . ir, thereby enabling the second party to de-conmoit 
CM*^ CM'^. . . CM^' so as to reveaUng jJ\ . . L^' to the first party; 

C. the first party causing a third party to receive a credit amount CR, and a 
fourth party to be debited by a debit amount D. 
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